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SECTION  1 


FINDINGS 


1.  INTRODUCTION 


The  Federal  Aviation  Administration  (FAA)  maintains  many  navigational  aides  and 
communications  facilities  to  promote  and  ensure  safe  and  efficient  air  traffic  flow. 
Advances  in  technology  are  enabling  the  FAA  not  only  to  develop  more  effective  and 
sophisticated  navigation  equipment  but  also  to  reduce  its  maintenance  and  operations  cost 
by  developing  a  comprehensive  Remote  Maintenance  Monitoring  System  (RMMS).  Individual 
equipment  sites  will  be  monitored  by  Remote  Monitoring  Subsystems  (RMSs)  which  will 
report  to  Maintenance  Processor  Subsystems  (MPSs).  Eventually  the  RMMS  system  will  take 
on  a  broad  range  of  support  services  in  addition  to  remote  monitoring  and  certification  of 
navigation  and  related  equipment.  The  national  Maintenance  Management  System  (MMS),  a 
far-reaching  program  for  automating  maintenance,  personnel  and  logistic  functions  in  the 
Airway  Facilities  branch  (AAF)  of  FAA  will  also  utilize  the  MPSs. 

The  Remote  Maintenance  Monitoring  System /Maintenance  Management  System 
requires  the  support  of  a  communications  utility  to  connect  the  Maintenance  Processor 
Subsystems  (MPSs)  and  their  subordinate  Remote  Monitoring  Subsystems  (RMSs)  and  work 
centers  into  an  integrated  system.  It  is  expected  that  the  National  Airspace  Data 
Interchange  Network  (NADIN)  will  provide  the  communications  function  for  RMMS  and 
MMS. 

Under  FAA  Contract  DOT-FA79WA-4355,  Network  Analysis  Corporation  (NAC)  is 
investigating  the  technical  feasibility  of  using  NADIN  to  support  the  communications  needs 
of  a  number  of  candidate  services,  including  RMMS.  Task  7  of  this  contract  specifically 
directs  that  NAC,  with  input  from  AAF  program  personnel,  shall  formulate  a  traffic  and 
performance  requirements  profile  for  RMMS  and  determine  the  architectural  extensions  and 
network  enhancements  to  N  ADIN  necessary  to  support  RMMS. 

Initial  efforts  on  Task  7  identified  RMMS  traffic  and  performance  requirements. 
These  requirements  were  used  as  the  basis  for  a  design  analysis  which  resulted  in  a  set  of 
fir-lings  and  recommendations  regarding  NADIN  extensions  to  support  RMMS.  These 
activities  and  results  have  been  synthesized  in  this  document  which  is  Contract 
Deliverable  C3. 
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1.1  Objectives 


The  purpose  of  this  study  is  to  determine  if  and  how  NADIN  can  adequately  support 
the  communications  requirements  of  the  RMMS  and  MMS  programs.  NADIN  was  designed  as 
a  common  user  network  to  serve  initially  a  variety  of  non-intelligent  terminals,  particularly 
Area  B  terminals.  As  new  classes  of  users  such  as  the  MPSs  appear,  NADIN  will  be  called  on 
to  provide  new  services  to  meet  their  communications  needs.  This  memo  identifies  those 
services  and  the  enhancements  to  NADIN  which  will  best  provide  them. 

A  related  objective  of  this  study  is  to  assist  the  RMMS  and  MMS  programs  to  design 
their  geographically  dispersed  processors  to  function  as  a  coherent  system  capable  of 
orderly  growth  in  size  and  sophistication.  This  system  integration  is  crucial  to  the  success 
of  the  RMMS  and  MMS  programs. 

1.2  Summary  of  Findings 

The  analysis  and  requirements  profile  undertaken  in  this  study  resulted  in  a  number  of 
conclusions.  The  highlights  of  the  major  results  are  listed  below: 

e  The  NADIN  backbone  has  sufficient  capacity  to  handle  initial  RMMS  traffic  at 
adequate  performance  levels. 

e  An  X.25  compatible  interface  for  the  NADIN  and  MPS  connection  is 
recommended. 

e  Additional  frame  routing  capabilities  at  the  NADIN  concentrator  and  front  end 
processors  are  required. 

•  NADIN  can  support  the  X.25  interface  for  initial  MPS  communication  with  no 
other  change  in  architecture. 
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•  Future  MPS  communications  will  be  best  served  by  a  fully  distributed  packet 
switched  NADIN  capable  of  supporting  complete  X.25  functions. 

•  NAD1N  concentrator  ports  must  be  added  -  initially  one  per  concentrator,  later 
an  average  of  four  additional  ports  per  concentrator. 

These  and  other  supporting  results  are  developed  in  detail  in  this  report. 

1.3  Organization 

This  report  is  organized  into  four  major  sections  and  nine  supporting  appendices.  The 
subjects  are: 

•  Section  2  -  BACKGROUND  -  This  section  presents  a  brief  overview  of  the 
RMMS/MMS  programs  required  to  understand  the  data  communications  issues 
addressed  in  this  report. 

•  Section  3  -  NETWORKING  ALTERNATIVES  -  This  section  describes  four  feasible 
approaches  for  NADIN  support  of  RMMS/MMS. 

•  Section  4  -  EVALUATION  OF  ALTERNATIVES  -  The  alternatives  described  in 
Section  3  are  compared  in  a  number  of  areas,  including  performance,  timeliness, 
flexibility  and  others. 

•  Section  5  -  RECOMMENDATIONS  -  An  alternative  is  chosen  from  among  the 
four.  Recommendations  for  implementing  this  alternative  are  made. 

The  appendices  contain  the  detailed  technical  basis  for  the  results  discussed  in  the 
report.  In  addition,  detailed  information  on  implementing  the  recommendations  as  well  as 
other  information  including  higher  level  protocol  issues  are  included. 
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SECTION  2 


BACKGROUND 


2.  INTRODUCTION 


This  section  presents  a  high-level  description  of  the  RMMS,  the  MMS  and  the  National 
Airspace  Data  Interchange  Network  (NADIN).  This  will  provide  the  background  for 
interpreting  the  results  and  analyses  in  subsequent  sections. 

2.1  RMMS  System  Description 

The  Federal  Aviation  Administration  (FAA)  uses  a  large  number  of  geographically 
dispersed  navigational  aides  (NAVAIDs)  to  facilitate  safe  and  efficient  use  of  the  National 
Airspace.  These  remote  devices  cover  a  wide  range  of  operational  roles  and  implementation 
technologies.  Each  must  be  periodically  certified  as  to  operability,  and  maintained 
accordingly.  This  has  been  historically  accomplished  by  manning  some  sites,  and  scheduling 
periodic  visits  to  others. 

Current  technology  offers  the  opportunity  to  substantially  improve  the  responsiveness 
of  the  monitoring  and  maintenance  activities,  and  at  the  same  time  reduce  the  cost  of  the 
present  labor-intensive  approach.  The  Airway  Facilities  Service  (AAF)  of  the  FAA  has 
operational  responsibilities  for  the  NAVAIDs,  and  is  pursuing  numerous  applications  of 
current  technology  to  enhance  the  maintenance  and  monitoring  activities.  In  particular, 
AAF  has  formulated  the  concept  of  a  Remote  Maintenance  Monitoring  System  (RMMS)  that 
will  provide  the  capability  to  (1)  automate  and  remotely  control  the  periodic  tasks  of 
equipment  performance  monitoring  and  the  recording  of  certification  parameter  data  and 
(2)  support  fault  isolation,  diagnostic  testing,  and  uplink  servo  control. 

2.1.1  RMMS  Functions 


The  RMMS  will  replace  many  routine  maintenance  functions  currently  performed  at 
remote  equipment  sites  and  will  permit  them  to  be  accomplished  at  any  suitably  equipped 
work  station.  Numerous  functions  have  been  identified  for  the  RMMS  (Reference  8);  the 


first  three  functions  will  be  implemented  with  the  initial  introduction  of  RMMS  equipment. 
As  state-of-the-art  replacement  equipment  is  introduced  in  the  National  Airspace  System 
(NAS),  and  operational  experience  is  obtained  with  the  initial  RMMS,  the  remaining 
functions  may  be  implemented.  These  functions  include  but  are  not  limited  to: 

(1)  Initial 

(a)  Real-Time  Monitor  and  Alarm 

(b)  Certification-Parameter  Logging 

(c)  Remote  Control 

(2)  Future 

(a)  Automatic  Recordkeeping  and  Information  Retrieval 

(b)  System  Performance  Trend  Analysis 

(c)  Remote  Diagnostics 

(d)  Uplink  Equipment  Adjustments 

(e)  Failure  Anticipation 

(f)  Historical  File  of  System  Problems  and  Solutions 
2.1.2  RMMS  Structure 


The  RMMS  will  consist  of  four  types  of  physical  elements.  These  elements  are: 

1.  Remote  Monitoring  Subsystems  (RMS) 

2.  Maintenance  Processor  Subsystems  (MPS) 

3.  Terminal  System  (both  fixed  and  portable) 

4.  Telecommunication  Network  (TCN) 

Figure  2-1  is  an  overall  block  diagram  of  the  RMMS  illustrating  the  hierarchical 
relationship  between  the  major  elements  of  the  system.  The  RMS  will  consist  of  equipment 
at  the  remote  facility  site  to  perform  facility  monitoring,  data  acquisition,  and  alarm 
reporting  functions.  The  MPS  will  act  as  the  hub  of  the  RMMS  to  collect,  record,  and 
analyze  facility  data,  and  to  distribute  it  to  appropriate  locations.  Fixed  terminals  will  be 
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provided  at  work  centers  to  enable  the  MPS  to  alert  maintenance  technicians  of  alarm 
conditions  as  well  as  to  permit  the  technicians  to  query  the  MPS  for  status  information. 
Portable  terminals  will  be  used  by  technicians  at  facilities  to  obtain  immediate  status 
information  on  a  collocated  facility  directly  or  information  on  a  remote  facility  via  the 
MPS.  All  information  transfers  between  the  MPS  and  each  RMS  and  the  terminal  locations 
will  be  accomplished  through  the  TCN. 

2.2  Maintenance  Management  System  (MMS) 

The  MMS  (Reference  2)  will  be  an  administrative  and  technical  support  system 
designed  to  automate  the  collection,  storage,  analysis  and  distribution  of  data  as  well  as  the 
monitoring  of  administrative  and  technical  functions.  This  system  will  allow  various  levels 
in  the  Airway  Facilities  Service  (AAF)  hierarchy  the  capability  to  input,  access  and  process 
the  information  required  to  administer  AAF  programs  efficiently.  Examples  of  some  of  the 
many  programs  which  will  be  managed  with  the  use  of  this  system  are: 

•  Facility  logs 

•  Equipment  performance  data 

•  Trouble  shooting  data 

•  Logistics  inventory 

•  Equipment  failure  analysis 

•  Facilities  master  file 

MMS  software  will  share  the  Maintenance  Processors  with  the  RMMS  software. 

Substantial  amounts  of  data  will  be  provided  to  the  MMS  by  the  RMMS.  When  required  at 
regional  offices,  National  Headquarters  or  National  Support  Group,  necessary  information 
can  be  forwarded  upon  request  or  on  a  scheduled  basis  via  the  TCN.  The  MMS  program 
concept  is  currently  under  development.  The  number,  type  and  location  of  MMS  processors 
has  not  yet  been  determined  but  tentative  plans  call  for  MMS  functions  at  Enroute  MPSs, 


general  NAS  Sector  MPSs,  regional  processors  and  possibly  one  or  more  national  MM8 
processors.  The  full  capability  of  the  Maintenance  Management  System  will  be  phased  in 
with  the  complete  deployment  and  implementation  of  the  Remote  Maintenance  Monitoring 
System.  To  provide  early  guidance  to  the  MMS  program,  this  memo  qualitatively  defines  the 
communications  requirements  needed  for  NADIN  support  of  the  MMS.  ' 

2.3  Implementation  Phases 

The  RMMS  program  will  be  implemented  in  steps  over  the  next  6  to  10  years.  For  the 
purposes  of  this  NADIN  support  study,  the  RMMS  implementation  is  described  in  three  parts. 
These  are  labeled  Phase  I,  Phase  n  -  Scenario  I  and  Phase  II  -  Scenario  II.  These  are 
described  below.  ! 

2.3.1  Phase  I  (1981-1983) 

The  initial  phase  of  RMMS  includes  the  Enroute  MPSs,  the  Remote  Center  Air/Ground 
(RCAG)  RMS,  the  Second  Generation  VHF  Omni  Range/Tactical  Air  Navigation  (VORTAC) 
RMS,  the  workcenters  and  the  associated  fixed  and  portable  technician  terminals.  This 
system  is  being  installed  in  1981  through  1983.  Complete  operation  of  Phase  I  is  scheduled 
to  occur  in  early  1984.  MMS  functions  at  the  Enroute  MPSs  are  also  scheduled  for 
completion  by  kte  1983.  These  are  included  in  Phase  I  but  no  traffic  data  is  available  for 
MMS.  Hence,  Phase  I  traffic  does  not  include  MMS  traffic. 

2.3.2  Phase  II,  Scenario  I  (1984-1987) 

In  the  time  period  1984-1987,  approximately  80  general  NAS  Sector  MPSs  are  to  be 
installed,  one  in  each  AF  sector.  Possible  locations  for  the  Sector  MPSs  are  Air  Traffic 
Control  Towers  (ATCT),  Automated  Flight  Service  Stations  (AFSS)  or  AF  Sector  Offies. 
During  this  period  additional  systems  may  be  remotely  monitored  via  new  RMSs  tied  to  the 
MPS  network.  However  for  a  basis  of  comparison,  Phase  II  -  Scenario  I  is  defined  as  simply 
Phase  I  plus  the  general  NAS  Sector  MPSs.  The  traffic  and  throughput  computations  in 
Appendix  F  are  based  on  this  definition. 
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2.3.3  Pliase  n,  Scenario  n  (1987-1990) 


Many  facilities  are  candidates  for  future  remote  monitoring.  It  is  not  clear  yet  which 
of  the  many  candidate  systems  will  in  fact  be  monitored  by  RMSs  or  when  this  will  happen. 
Therefore  for  sizing  purposes  Phase  n  -  Scenario  II  is  defined  as  the  RMMS  system  which 
would  exist  if  aU  of  today's  candidates  for  RMS  systems  are  implemented.  In  addition  to 
Phase  I  and  the  general  NAS  Sector  MPSs,  the  Remote  Monitoring  systems  included  in 
Phase  n  -  Scenario  II  are: 

•  Radar  Microwave  Link  (RML)  -  720  sites 

•  Medium  Intensity  Approach  Lighting  System  (MALSR)  -  621  sites 

•  Air  Route  Surveillance  Radar  -  89  sites  (ARSR-3  and  ARSR-4) 

•  Runway  Visual  Range  (RVR)  -  400  sites 

•  Airport  Surveillance  Radar  (ASR)  -  207  sites  (ASR-7/8  and  ASR-9) 

•  Approach  Lighting  System  w/Sequenced  Flashes  (ALSF)  -  75  sites 

•  Instrument  Landing  System  (ILS)  -  1028  sites 

•  Visual  Approach  Slope  Indicator  (VASI)  -  631  sites 

•  Remote  Transmitter/Receiver  (RTR)  -  700  sites 

•  Doppler  VHF  Omni-range  (DVOR)  -  60  sites 

•  Remote  Communications  Outlet  (RCO)  -  282  sites  (includes  FSSs  to  be 
closed/part-timed) 

•  Backup  Emergency  Communications  (BUEC)  -  255  sites 

•  Distance  Measuring  Equipment  (DME)  -  310  sites 


2-6 


•  Direction  Finder  (DF)  -  293  sites 


•  VHF  Omni-range  Test  Signal  (VOT)  -  103  sites 

•  Non-Directional  Beacon  (NDB)  -  600  sites 

•  Microwave  Landing  System  (fi>»L-8)  -  1250  sites 

•  Beacon  Only  -  20  sites 

Phase  II  -  Scenario  n  represents  the  extreme  case  of  100  percent  implementation  of  all 
current  RMS  candidates.  This  can  be  compared  with  the  bare  bones  case  of  Phase  n  - 
Scenario  I  to  obtain  upper  and  lower  bounds  for  expected  future  requirements  of  RMMS  for 
NADIN  communications  support. 

2.4  MPS  to  MPS  Communications  Overview 


Each  MPS  (Reference  7)  will  act  as  a  central  processing  and  control  point  to  collect, 
record,  and  analyze  monitored  data  and  to  issue  commands  to  all  of  its  assigned  RMSs.  The 
MPS  will  also  be  responsible  for  the  display  of  monitored  data  and  the  maintenance  of  an 
historical  record  of  reported  data.  The  MPS  will  receive  periodic  status  and  certification 
reports  from  the  associated  RMSs.  Alarm  conditions  will  also  be  reported  to  the  MPS  from 
the  RMS  upon  occurrence  Phase  I  RMMS  implementation  calls  for  Enroute  MPSs  at  each 
Air  Route  Traffic  Control  Center  plus  Oklahoma  City  and  possibly  Atlantic  City.  In 
Pha^e  II,  approximately  eighty  (80)  General  NAS  Sector  MPSs  will  be  installed.  Possible 
locations  for  these  are: 

•  Sector  Offices 

•  Combined  Stations  and  Towers  (CS/T) 

•  Flight  Service  Stations  (FSS) 

Figure  2-2  shows  the  connections  to  a  typical  center  MPS  in  Phase  I  of  the  RMMS 
implementation. 
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TRAFFIC  CONTROL  CENTER  (ARTCC) 


CONNECTED  ELEMENTS 


The  Enroute  MPSs  will  be  Tandem  T16  minicomputers  located  at  the  ARTCC  while  the 
general  NAS  Sector  MPSs  have  not  yet  been  selected.  These  machines  perform  monitoring, 
certification  assistance  and  record  keeping  tasks  for  the  various  Remote  Monitoring 
Subsystems  as  well  as  communications  support  for  fixed  and  portable  terminais. 

A  detailed  description  of  the  Remote  Maintenance  Monitoring  System  is  provided  in 
Appendices  A  and  B.  The  MPS  will  also  house  the  MMS  software.  Details  of  how  MMS  will 
function  and  its  precise  relation  to  RMMS  software  are  not  yet  determined.  In  addition,  the 
MPSs  will  collect,  store  and  retrieve  data  for  the  national  Maintenance  Management  System 
(MMS)  (Reference  16).  To  understand  the  architectural  enhancements  required  by  NADIN  to 
support  MPS  to  MPS  communications,  it  is  necessary  to  characterize  the  functions  of  this 
system. 

2.4.1  MPS  to  MPS  Functions 


In  the  initial  phase  of  the  RMMS,  traffic  from  MPS  to  MPS  will  consist  of: 

•  alarm  messages  -  short,  high  priority  messages  requiring  end-user 
acknowledgement, 

•  file  updates  -  short  to  medium  (1,000  characters)  status  or  certification 
reports, 

•  free  format  terminal  requests  -  technicians  requesting  support  data  to  assist  in 
diagnosing  or  effecting  repairs, 

•  replies  to  data  base  queries  -  short  to  medium  length  responses  to  MPS- 
generated  or  human-generated  requests. 

In  later  phases  of  the  national  Maintenance  Management  System,  large  scale  file 
updates  and  perhaps  file  transfers  will  become  common  between  MPSs.  The  initial  concept 
is  that  only  MPS  computers  and  their  subsidiary  terminals  will  exchange  information. 
However,  the  possibility  should  not  be  excluded  that  in  the  future  it  may  be  desirable  to 
allow  access  to  other  authorized  users.  Possible  candidates  are  the  ATC  computer  (9020  or 
9020R)  and  the  flow  control  computer  in  Jacksonville. 
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2.4.2  MPS  Traffic 


The  bulk  of  MPS  to  MPS  traffic  will  be  between  Enroute  MPSs  and  Sector  MPSa  in  the 
same  enroute  air  traffic  area.  (Throughput  details  are  discussed  in  Appendix  A.)  Most  of 
the  remaining  traffic  is  between  MPSs,  both  Enroute  and  Sector,  in  adjacent  enroute  areas. 
All  RMMS  and  MMS  traffic  which  enters  NADIN  uses  the  MPS/NADIN  concentrator 
interface. 

Several  observations  can  be  drawn  from  the  above  overview  of  MPS  to  MPS 
communication. 

•  MPS  traffic  does  not  require  the  message  processing  functions  of  the  NADIN 
message  switch, 

•  MPS  traffic  requires  local  routing  from  NADIN, 

•  RM  MS/M  MS  needs  efficient  handling  of  large  files, 

•  RMMS  alarms  require  fast  delivery  (3  second  MPS  to  MPS  delay), 

•  RMMS  traffic  patterns  do  not  follow  the  NADIN  double  star  topology. 

The  possible  networking  approaches  to  provide  NADIN  support  of  MPS  to  MPS  communica¬ 
tion  are  discussed  in  the  next  section.  A  number  of  higher  level  protocol  issues  for  MPS 
host-to-host  consideration  are  discussed  in  Appendix  G. 

2.5  The  National  Airspace  Data  Interchange  Network  (NADIN) 

The  FAA  is  in  the  process  of  implementing  a  common  user  data  communications 
network  scheduled  for  operation  by  the  third  quarter  of  1983. 

NADIN  is  currently  being  developed  as  a  centralized  network.  It  includes  two 
interconnected,  centrally  located,  message-switch  nodes.  These  are  each  connected  by  a 


star-patterned  subnetwork  to  eleven  or  twelve  concentrator  nodes.  Figure  2-3  illustrates 
the  basic  elements  of  the  NAD1N  concept.  Under  the  Level  IA  implementation  the  link 
between  a  switch  and  each  associated  concentrator  consists  of  one  full-duplex,  voice-grade 
line,  operating  at  9,600  bits  per  second  (b/s).  The  link  between  the  two  switches  consists  of 
two  such  lines.  The  two  switches,  the  twenty-three  concentrators  and  the  links 
interconnecting  them  make  up  the  NADIN  backbone  network.  The  complete  network  can  be 
considered  to  also  include  the  various  ATC  data  terminals  and  computers  which  use  the 
NADIN  facilities  and  the  circuits  and  subnetworks  by  which  they  are  linked  to  the  backbone 
network. 

Typically,  a  NADIN  message  is  directed  from  the  originating  data  terminal  or 
computer  through  a  concentrator  to  the  associated  switch.  The  switch  then  routes  the 
message  to  its  destination  (terminal  or  computer)  by  way  of  the  other  switch,  if  necessary, 
and  the  concentrator  to  which  the  destination  is  linked.  Variations  to  this  typical  routing 
include  local  switching  at  the  concentrators  for  certain  message  traffic  and  the  entry/exit 
at  the  switches  for  message  traffic  involving  external  systems  (e.g.,  WMSC  and  International 
AFTN). 

The  NADIN  concentrators  are  intelligent  statistical  multiplexors.  Their  major 
functions  include: 

e  limited  message  processing,  e.g.,  code  and  format  conversion; 

•  local  switching  of  pertinent  traffic,  including  the  collection  and  periodic 
forwarding  of  statistics  on  such  traffic  to  the  central  switch; 

•  application  of  link-level  protocols,  including  the  fragmenting/reassembly  of 
messages  into/from  ADCCP  frames; 

•  buffering  of  messages;  and 

e  multiplexing/demultiplexing  of  message  frames. 

Each  switch  consists  of  two  major  components  -  a  front-end  processor  (FEP)  and  a 
message  processor  (DS  714).  The  FEP  is  functionally  and  physically  similar  to  a  NADIN 
concentrator.  It  performs  the  actual  switching  functions.  All  links  to  the  NADIN  switch  are 
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SWITCHES  --  2  c-ATLANTA,  W-SALT  LAKE  CITY 

CONCENTRATORS  —  23  AT  EACH  ARTCC  AND  ANCHORAGE,  HONOLULU.  AND 
SAN  JUAN 

TERMINALS  —  UP  TO  ABOUT  50  PER  CONCENTRATOR  THROUGHOUT  EACH 
ARTCC  AREA,  PLUS  SOME  AT  SWITCHES.  SOME  ON  DEDICATED 
CIRCUITS,  MOST  ON  MULTIPOINT 

EXTERNAL  SYSTEMS  AND  NETWORKS,  E.G.,  INTERNATIONAL  AFTN,  WMSC 


CENTER  MRS  ( CURRENTLY  NOT  PART  OF  NADIN) 


FIGURE  2-3:  NAD  IN  SCHEMATIC 


through  the  FEP.  The  DS  714  is  a  computer  with  associated  peripheral  equipment  (e.g.,  tape 
and  disk  drives).  Its  functions  inolude: 

•  message  editing, 

•  message  routing, 

•  message  recording/recovery, 

•  accounting,  and 


•  network  control. 


SECTION  3 


NETWORKING  ALTERNATIVES  FOR  NADIN  SUPPORT  OF  RMMS 


3.  INTRODUCTION 


Four  feasible  networking  approaches  to  provide  MPS  to  MPS  communications  via 
NADIN  are  described  in  this  action.  All  of  these  candidates  take  as  starting  points  the 
NADIN  IA  architecture  and  the  MPS  to  MPS  communications  requirements  outlined  in 
Section  2. 

3.1  Alternative  1 


The  first  approach  for  NADIN  to  satisfy  MPS  to  MPS  requirements  is  to  make  minimal 
modifications  to  NADIN  IA.  That  is,  NADIN  retains  the  double  star  topology  with  message 
processing  at  the  switch.  In  particular,  no  new  backbone  nodes  are  added.  In  this  approach, 
the  MPS  would  deliver  data  to  the  NADIN  concentrator  as  messages  segmented  into  frames 
in  the  manner  of  the  FSAS/NADIN  interface  (Reference  3).  The  messages  would  be  limited 
to  3700  characters,  the  frames  to  245  characters  (NADIN  standards).  Message  format  would 
be  the  NADIN  information  message  format  (Reference  4). 

The  concentrator  would  scan  the  message,  build  a  NADIN  transport  header  as 
described  in  Reference  5,  and  ship  the  message  upstream,  frame  by  frame,  to  the  NADIN 
message  switch  for  routing.  The  NADIN  message  processor  at  the  switching  center  would 
also  check  the  MPS  message  for  format  errors  just  as  it  does  for  teletype  messages  before 
passing  the  message  on  through  the  network  for  delivery. 

The  exception  to  this  procedure  is  for  local  traffic,  i.e.,  origin  and  destination  in  the 
same  Enroute  Area,  which  can  be  routed  by  the  concentrator  itself.  Local  switching  of 
RMMS  traffic  constitutes  an  enhancement  of  the  limited  local  switching  capability  to  be 
included  in  NADIN  IA  for  FDIO  traffic. 


3.2  Alternative  2 


This  alternative  retains  the  topology  and  hardware  configuration  of  NADIN  !A, 
However,  there  are  several  significant  changes  in  the  way  the  MPS  passes  data  to  the 
network  and  the  way  in  which  the  routing  function  is  carried  out. 

The  MPS  passes  data  to  the  NADIN  concentrator  in  frames,  maximum  length  of 
2 5*3  characters  including  link  level  headers  and  trailers.  Each  frame  contains  a  transport 
header  supplied  by  the  MPS,  not  by  NADIN.  The  first  four  octets  of  this  transport  header 
contain  priority  and  addressing  information.  The  latter  portion  of  the  transport  header  is 
for  use  by  the  two  communicating  MPS  hosts  and  is  ignored  by  NADIN. 

The  NADIN  concentrator  reads  the  transport  header  address  and,  assuming  it  is  a 
recognizable  non-local  network  address,  passes  the  frame  upstream  to  the  front  end 
processor  (FEP)  at  the  switching  center.  The  FEP,  based  on  the  transport  header,  routes  the 
frame  to  the  appropriate  network  exit  point  (concentrator).  Routing  is  fixed.  The  frame 
never  goes  to  the  message  processor  (DS714).  Consequently  these  frames  are  not 
retrievable  from  NADIN,  unlike  NADIN  accountable  message  traffic.  The  MPS  takes  this 
responsibility. 

Local  traffic  will  be  switched  by  the  concentrator  itself  without  the  involvement  of 
the  FEP. 

3.3  Alternative  3 


This  alternative  retains  the  NADIN  1A  topology  but  requires  the  enhancement  of 
NADIN  to  support  X.25  interfaces.  However,  NADIN  would  not  initially  become  a  packet- 
switched  network  internally.  The  MPS  would  present  packets  to  the  NADIN  concentrator. 
Virtual  circuits  between  the  MPS  hosts  would  be  established  by  call  request  and  call  accept 
packets.  Datagram  service  might  also  be  used  by  the  MPSs.  However,  internally  NADIN 
would  not  move  the  packets  via  virtual  circuits.  This  concept  of  virtual  circuits  supported 
by  an  underlying  network  without  virtual  circuits  is  discussed  in  Reference  6. 

The  NADIN  FEP  and  concentrators  would  aloo  be  modified  as  in  Alternative  2.  The 
concentrator  would  perform  local  switching  for  local  traffic  while  packets  for  remote 
addresses  would  be  forwarded  to  the  FEP  at  the  NADIN  switching  center.  The  FEP  would 
route  this  traffic  directly  to  the  appropriate  N  ADIN  concentrator.  As  in  Alternative  2  the 
packets  from  the  MPS  would  completely  bypass  the  message  processors  (DS  714sl  at  the 
N\DIN  switching  centers. 
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The  mechanism  fop  conveying  routing  information  from  the  concentrator  to  the  FEP 
would  be  a  concentrator  built  transport  header  as  described  in  Reference  5. 

The  NADIN  concentrator  would  require  software  modifications  to  establish  a  mapping 
between  virtual  circuit  numbers  (permanent  or  temporary)  and  network  addresses.  The 
NADIN  exit  point  would  have  to  do  the  reverse  mapping,  possibly  holding  packets  for  correct 
sequencing,  then  passing  the  packets  to  the  receiving  MPS  with  the  expected  virtual  circuit 
number  appended. 

This  alternative  provides  the  MPSs  with  the  ability  to  interface  to  a  packet-switched 
network.  If  and  when  NADIN  becomes  a  full  packet-switched  network  the  MPS/NADIN 
interface  would  require  virtually  no  additional  modification. 

3.4  Alternative  4 

This  alternative  consists  of  the  MPS  interfacing  to  NADIN  via  X.25  to  a  packet- 
switched  NADIN  with  increased  connectivity.  Additional  backbone  links  would  be  added  to 
NADIN  as  proposed  in  NAC's  Computer  B  Report  (Reference  8).  A  possible  configuration  is 
shown  in  Figure  3-1.  Note  that  NADIN  IA  backbone  nodes  are  retained  under  alternative 
four.  The  composition  and  function  of  the  nodes  would  be  changed,  however;  e.g.,  packet 
switch  modules  (PSMs)  would  be  added.  Under  the  NADIN  IA  architecture,  there  are  two 
types  of  nodes: 

•  message-switch  nodes  at  the  Atlanta  and  Salt  Lake  City  ARTCCs,  which  also 
include  concentrators;  and 

•  concentrator  nodes  at  the  18  other  CONUS  ARTCCs  and  at  three  off-shore 
ARTCCs  (Anchorage,  Honolulu  and  San  Juan). 

Alternative  4  would  result  in  three  types  of  nodes: 

•  combined  message-switch,  packet-switch  nodes  at  the  Atlanta  and  Salt  Lake 
City  ARTCCs,  which  would  also  include  concentrators; 

•  packet-switch  nodes  at  the  18  other  CONUS  ARTCCs,  which  would  also  include 
concentrators;  and 

•  concentrator  nodes  at  the  three  off-shore  ARTCCs. 
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FIGURE  3-1:  OPTIMAL  ALTERNATIVE  4  CONFIGURATION 


The  three  off-shore  nodes  would  remain  essentially  unchanged  for  this  initial 
Distributed  Packet  Switched  Network  application.  This  is  practical  since  it  would  be 
unlikely  that  they  would  be  selected  as  part  of  alternate  routes  for  messages  between  other 
nodes,  and  they  are  not  expected  to  generate  much  NADIN  backbone  traffic.  Each  of  the 
off-shore  concentrators  would  be  linked  directly  to  the  PSM  at  a  convenient  packet-switch 
node.  Those  concentrators  would  thus  be  functionally  modified  in  the  same  manner  as  the 
other  20  concentrators. 

The  modifications  to  the  two  message-switch  nodes  are  indicated  in  Figure  3-2.  The 
major  change  is  seen  to  be  the  addition  of  the  PSM  and  the  transfer  of  the  major  switching 
function  from  the  FEP  to  the  PSM.  The  FEP  would  continue  to  serve  as  the  front  end  for 
the  DS  714  and  as  a  gateway  for  external  systems.  The  concentrator  would  continue  to 
serve  as  the  backbone  network  access  point  for  ATC  and  other  data  terminals  and 
computers. 

The  other  CONUS  nodes  would  also  be  modified  to  include  PSMs.  This  is  illustrated  in 
Figure  3-3.  Under  this  enhanced  architecture  each  such  node  would  be  linked  to  a  number 
of  other  such  nodes  through  their  respective  PSMs.  In  general,  this  need  not  include  a  direct 
link  to  the  PSM  at  a  message-switch  node. 

Since  not  all  messages  will  be  directed  through  the  message-switch  node  under  the 
enhanced  architecture,  statistical  accounting  of  network  traffic  must  be  performed  at  the 
packet-switch  nodes.  The  PSMs  would  perform  the  accounting  relative  to  packet  traffic. 
The  concentrators  would  perform  the  accounting  relative  to  message  traffic.  Pertinent  data 
would  be  forwarded  to  the  message  switch  periodically  in  control  messages. 

The  enhanced  NADIN  architecture  would  require  some  form  of  virtual  circuit  service. 
Such  a  service  would  assure  the  efficient  handling  of  large  files  and  reports  without  the  need 
for  modification  of  host  computer  (e.g.,  MPS)  software.  For  general  efficiency  this  service 
might  best  take  the  virtual  call  form,  with  buffering  and  sequencing  provided  at  the 
receiving  concentrator  (or  associated  PSM).  Permanent  virtual  circuit  service  would  appear 
desirable  for  messages  between  adjacent  enroute  areas  with  overlapping  facility 
responsibilities.  Datagram  service  would  appear  optimal  for  alarm  messages.  The  ability  to 
handle  efficiently  the  complexities  of  identifying  and  separately  servicing  the  various 
classes  of  message  traffic  would  require  further  study. 

From  the  RMMS  side,  Alternatives  3  and  4  appear  the  same  except  for  (probably) 
better  NADIN  performance  under  Alternative  4.  The  MPS/NADIN  interface  would  be  X.25 
as  discussed  in  Alternative  3  with  the  MPS  presenting  packets  directly  to  the  NADIN  Packet 
Switch  Module  at  the  concentrator. 
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FIGURE  3-2:  MODIFICATION  OF  MESSAGE-SWITCH  NODES 


FIGURE  3-3:  MODIFICATION  OF  OTHER  CONUS  NODES 


SECTION  4 


EVALUATION  OF  ALTERNATIVES 


4.  INTRODUCTION 


The  alternatives  formulated  in  the  preceding  section  are  compared  below.  In  the  long 
term,  it  is  judged  that  NADIN  should  follow  Alternative  4,  the  full  packet-switched 
approach.  However,  timing  factors  point  to  Alternative  3,  the  X.25  interface  plus 
NADIN  I A  architecture,  as  the  best  approach  to  satisfy  initial  RMMS  and  MMS 
requirements. 

In  subsequent  sections  the  alternative  approaches  are  analyzed  from  several  points  of 
view.  In  Section  4.1  the  enhancements  to  NADIN  to  support  each  alternative  are  discussed. 
In  Section  4.2  a  detailed  analysis  of  network  performance  (throughput  and  delays)  is 
presented  for  Alternative  1.  Quantitative  performance  values  are  not  derived  for  the 
remaining  alternatives.  However,  their  expected  performance  relative  to  Alternative  1  is 
discussed  briefly.  The  alternatives  are  compared  in  Section  4.3  for  effectiveness, 
efficiency,  timeliness,  RMMS  futurity  and  NADIN  futurity. 

The  recommended  alternative  and  the  NADIN/RMMS  interface  are  described  in  detail 
in  Section  5. 

4.1  Enhancements  to  NADIN  by  Alternative 

This  section  describes  the  enhancements  to  NADIN  required  to  satisfy  RMMS 
requirements  for  each  of  the  four  network  alternatives  defined  in  Section  3. 

4.1.1  Alternative  1 


The  enhancements  to  NADIN  IA  are  separated  into  those  needed  for  Phase  I  and 
Phase  II  of  RMMS  and  MMS  as  described  in  Section  2. 


In  Phase  It 


•  All  NADIN  IA  link  capacities  are  adequate  for  RMMS  traffic  in  the  near  term. 

•  NADIN  concentrators  and  switches  are  adequate  to  handle  the  increased 
processing  load  imposed  by  RMMS. 

•  A  single  medium-speed  (2400  bit/sec)  port  will  be  needed  at  each  NADIN 
concentrator  for  the  Enroute  MPS. 

•  Software  must  be  modified  to  include  RMMS  ports  in  NADIN  address  tables  and 
to  carry  out  other  table  expansions. 

In  order  to  support  RMMS  traffic  in  Phase  II  several  enhancements  and/or 
architectural  extensions  are  required  for  NADIN.  These  are: 

•  Ports  -  At  each  NADIN  concentrator  an  average  of  four  additional  ports 
(2400  bit/sec)  will  be  needed  for  the  Sector  MPSs.  In  addition,  the  Enroute  MPS 
port  must  be  upgraded  to  4800  bit/sec  for  Phase  n  Scenario  I.  If  and  when 
traffic  rises  to  the  levels  of  Phase  H  Scenario  II  the  Enroute  MPS  interface  to 
NADIN  must  be  increased  to  accommodate  a  peak  flow  of  10,000  bit/sec.  If  the 
full  implementation  described  for  Phase  n  -  Scenario  II  actually  occurs  then 
either  dual  9.6  Kb/sec  ports  or  a  biplexed  19.2  Kb/sec  connection  would  be 
required.  It  is  difficult  to  predict  with  confidence  when  or  if  this  level  of 
throughput  across  the  NADIN  concentrator /Enroute  MPS  port  will  occur.  For 
the  period  1984-1987  at  least,  it  is  likely  that  a  9600  bit/sec  interface  will 
suffice.  It  is  only  at  the  point  when  more  than  approximately  half  of  the 
candidate  sites  of  Phase  n  -  Scenario  II  for  RMS  are  implemented  that 
9.6  Kb/sec  will  become  inadequate. 

•  Local  Switching  -  An  enhanced  local  switching  capability  is  required  at  the 
NADIN  concentrators  to  switch  local  traffic  between  the  Enroute  MPS  and 
Sector  MPSs.  In  NADIN  IA  this  function  is  provided  only  for  FDIO  traffic. 

•  Processor  Capacity  -  Throughput  at  the  NADIN  concentrators  will  rise 
dramatically  in  Phase  n.  Under  Scenario  II  the  total  gross  input  into  the  busier 
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NADIN  concentrator  will  rise  to  nearly  21,000  bit/sec,  approximately  triple  the 
NADIN  1A  base  level  of  6,900  bit/sec  (gross  bits  including  overhead).  While  it  is 
possible  that  the  full  Scenario  n  load  may  not  be  realized  by  1990,  there  will  in 
any  case  be  a  very  significant  increase  in  the  concentrator  processing  load  in  the 
late  1980s.  The  reason  for  this  is  that  traffic  between  Sector  MPSs  and  their 
local  Enroute  MPS  will  be  locally  switched  by  the  NADIN  concentrator. 
Table  4-1  shows  the  input  sources  to  the  NADIN  concentrator.  NADIN  IA  gross 
traffic  is  derived  in  Appendix  D,  based  on  Table  Z-9,  Reference  4. 

The  precise  capacity  and  design  of  the  Level  IA  concentrators  is  not  yet 
determined.  Thus  a  quantitative  assessment  of  the  increase  needed  in  processor 
capacity  is  not  possible.  This  is  an  area  which  can  be  identified  as  important  for 
further  study  as  NADIN  and  RMMS  development  progresses.  However,  this  is 
precisely  the  type  of  incremental  capacity  expansion  which  the  modular  design 
of  the  NADIN  concentrators  is  intended  to  facilitate. 

•  NADIN  Backbone  Capacity  -  NADIN  I A  link  capacities  are  sufficient  to  handle 
Phase  I  and  Phase  II  -  Scenario  I  of  RMMS  with  no  difficulty.  No  increases  in 
trunk  capacity  are  needed  to  satisfy  NADIN  end  to  end  delay  requirements  for 
either  of  these  two  cases.  However,  this  assessment  is  based  on  the  assumption 
that  no  additional  traffic  beyond  NADIN  IA  and  RMMS  uses  NADIN.  By 
1987-1990  it  is  likely  that  additional  users  such  as  NAS-to-NAS  and  others  will 
be  added  to  NADIN.  However,  based  strictly  on  NADIN  IA,  plus  RMMS,  the 
traffic  load  under  Phase  II  -  Scenario  n  could  be  supported  by  NADIN  IA  link 
capacities.  However,  utilization  would  be  near  critical  levels  (.70)  on  the 
heaviest  links  which  would  create  extreme  sensitivity  to  any  unplanned  traffic 
growth.  The  cumulative  effect  of  adding  RMMS,  NAS-to-NAS  and  other  traffic 
to  NADIN  is  being  examined  by  NAC  under  Task  13  of  this  contract. 

4.1.2  Alternative  2 


Under  Alternative  2,  backbone  and  port  requirements  are  the  same  as  for 
Alternative  1.  However,  processing  loads  at  the  NADIN  concentrator  and  switch  should  be 
reduced  significantly  since  virtually  no  message  processing  is  done  by  either  concentrator  or 
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ENVIRONMENT 


SOURCE* 


IA  Base 

E  MPS 

Sector  MPS 
,S  (RMMS) 


NO.  OF 
PORTS 


NADIN 

IA 

RWS 

PHASE  I 

RMMS 

I'HASE  II 

SCENARIO  I 

RMMS 

PHASE  II 

SCENARIO  II 

6,900 

6,900 

6,900 

6,900 

- 

330 

1,580 

10,000 

- 

- 

70 

1,600 

- 

330 

330 

2,170 

6,900 

7,560 

8,880 

20,670 

TO'  *L 


*  LEGEND: 

IA  =  NADIN  IA 
E  MPS  =  ENROUTE  MPS 
Sector  MPS  =  GENERAL  NAS  SECTOR  MPS 
NS  (RMMS)  =  NADIN  SWITCH  TRAFFIC  -  RMMS  ONLY 


TABLE  4-1:  GROSS  INPUT  TO  NADIN  CONCENTRATOR  (BIT/SEC) 


switch.  Unlike  Alternative  1,  the  NADIN  concentrator  under  this  alternative  does  not  need 
to  build  the  NADIN  transport  header  for  RMMS  traffic. 

Software  modifications  at  both  the  concentrator  and  front  end  processor  are  required 
to  enable  NADIN  nodes  to  recognize  the  MPS  transport  header  and  to  take  appropriate 
routing  action  based  on  it.  Included  in  this  routing  is  local  routing  by  the  concentrator.  A 
substantial  address  table  would  be  required  at  the  FEP  to  carry  out  its  expanded  routing 
responsibilities  under  Alternative  2.  However  other  NADIN  traffic,  particularly  data  from 
teletypes  and  non-intelligent  terminals,  will  be  handled  exactly  as  in  NADIN  I  A.  Hence 
virtually  no  modifications  to  the  message  processors  at  the  switching  centers  are  required. 

4.1.3  Alternative  3 


Under  Alternative  3,  NADIN  backbone  and  port  requirements  are  the  same  as  for 
Alternatives  1  and  2.  The  FEP  routing  enhancements  are  essentially  the  same  as  in 
Alternative  2.  At  the  NADIN  concentrator,  the  X.25  RMMS/NADIN  interface  will  require 
considerable  software  modification.  Since  NADIN  will  not  be  using  virtual  circuits 
internally  in  this  scenario,  software  will  have  to  perform  the  exchanges  with  the  MPS  and 
the  network  needed  to  make  the  end-to-end  connection  appear  to  be  a  virtual  circuit  to  the 
two  MPS  end  users.  Dynamic  tables  linking  messages,  origin-destination  pairs  and  virtual 
circuit  numbers  will  have  to  be  maintained  at  the  network  exit  and  entry  points.  Buffer 
space  must  be  allocated  at  the  network  exit  concentrator  to  store  frames/packets  for 
possible  resequencing.  Analysis  would  be  needed  to  determine  the  required  amount  of 
additional  concentrator  buffering  required  for  this  alternative.  The  processing  load  at  the 
concentrators  will  increase  somewhat  due  to  the  overhead  of  converting  packets  into  NADIN 
frames  and  reverse. 

The  outstanding  feature  of  Alternative  3  is  that  the  MPSs  themselves  are  easy  to 
modify  for  the  X.25  interface.  The  machines  being  used  (at  least  for  the  Enroute  MPS)  are 
Tandem  T16s  which  are  available  with  an  optional  off  the  shelf  X.25  software  package 
(GUARDIAN/EXPAND). 

4.1.4  Alternative  4 


Under  Alternative  4,  port  requirements  would  remain  about  the  same  as  for  the  other 
alternatives  but  throughput  across  the  MPS/NADIN  interface  could  be  slightly  reduced  due 
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to  the  savings  in  overhead  gained  by  the  virtual  circuit  approach.  Backbone  links  would  be 
added  to  make  NADIN  more  highly  connected  and  allow  for  alternate  routing  and  congestion 
avoidance.  Packet  Switch  Modules  (PSMs)  or  the  enhancement  of  the  concentrators  and 
PEPs  to  perform  the  function  of  PSMs  would  be  needed  at  20  CONUS  ARTCCs  and  two 
switching  centers. 

Software  changes  at  the  concentrators,  FEPs  and  message  processors  would  be  needed. 
Routing  functions  would  have  to  be  distributed  throughout  the  network.  Network  control 
must  become  more  distributed.  Certain  classes  of  messages  would  however  continue  to  be 
routed  to  the  message  processor  for  editing  and  retrieval  purposes  just  as  in  NADIN  I  A. 

4.2  Performance  Analysis 

An  analysis  of  network  throughput  and  delay  was  performed  to  determine  the  adequacy 
of  NADIN  backbone  capacity  and  interface  speeds.  For  Alternative  1,  the  NADIN  I A 
approach,  detailed  network  queueing  models  were  used  to  obtain  average  delays  under 
various  loads.  For  Alternatives  2  and  4  delays  would  be  less  than  for  Alternative  1  because 
the  time  consuming  message  processing  at  the  switching  centers  is  eliminated.  However,  a 
quantitative  analysis  for  these  scenarios  is  beyond  the  resources  of  this  study.  For 
Alternative  3  the  additional  processing  and  address  translation  are  expected  to  cause  delays 
that  would  be  slightly  greater  than  those  for  Alternative  1.  The  net  result  of  the 
performance  analysis  is  to  show  that  the  NADIN  IA  backbone  capacity  is  sufficient  for 
Alternatives  t,  2,  3  and  4  at  least  for  Phase  I  and  Phase  II  -  Scenario  I.  However 
Alternative  4  also  assumes  additional  links  to  provide  alternate  routing;  hence,  Alternative  4 
performance  should  be  substantially  better  than  Alternative  1  performance. 

4.2.1  Alternative  1  -  Phase  1  Performance 


In  the  initial  phase  (1983-1984),  introduction  of  RMMS  traffic  between  Enroute  MPSs 
will  have  a  minimal  effect  on  the  NADIN  backbone  links.  Specifically: 

•  NADIN  throughput  will  increase  on  the  busiest  link  by  a  maximum  of  6.3  percent 
above  NADIN  I A  base  level  to  a  utilization  of  .508. 


•  Average  NADIN  network  delays  from  a  concentrator  to  a  switch  to  the  other 
switch  to  a  concentrator  will  increase  approximately  3  percent.  These  delays 
are: 

1.81  seconds  -  during  file  transfer  periods,  and 

1.07  seconds  -  in  the  absence  of  file  transfers 

•  NADIN  will  continue  to  meet  the  average  end-to-end  delay  requirement  of 
2  seconds  required  by  the  NADIN  Specification. 

The  computation  of  delays  is  discussed  in  detail  in  Appendix  F.  All  delays  are  for  peak  hour. 

One  of  the  important  questions  in  this  feasibility  study  was  the  adequacy  of  the 
service  which  NADIN  would  provide  to  RMMS.  The  answer  for  the  near  term  is  that  NADIN 
will  more  than  meet  the  delay  and  throughput  requirements  for  RMMS  traffic  as  specified  in 
Appendix  E.  In  particular,  average  end-to-end  delay  in  peak  hour  from  an  Enroute  MPS 
through  NADIN  to  an  Enroute  MPS  associated  with  the  other  NADIN  switch  including  MPS 
processing  time  is: 

•  2.31  seconds  during  FSAS  and  AWP  file  transfers,  and 

•  1.76  seconds  during  normal  period. 

This  compares  favorably  with  the  3  second  average  delay  specified  in  Appendix  E.  The 
delays  listed  above  are  for  foul  weather  conditions  and  so  represent  worst  case  behavior. 
The  calculations  and  delay  model  are  described  in  Appendix  E. 

4.2.2  Alternative  1  -  Phase  II  Performance 


Addition  of  the  Phase  n  RMMS  traffic  will  increase  delays  and  throughput.  However, 
service  will  remain  within  NADIN  requirements  for  Scenario  I,  provided  NADIN  base  traffic 
is  still  at  the  IA  levels.  Network  delays  have  been  computed  for  Phase  n  -  Scenario  I  traffic 
but  not  for  Phase  n  -  Scenario  II.  For  Phase  n  -  Scenario  II  line  utilization  on  the  heaviest 
switch  to  concentrator  link  will  be  approximately  .70.  This  makes  significant  delays  a  very 
real  possibility  if  capacity  remains  unchanged.  However,  since  new  users  are 


very  likely  to  be  using  the  network  by  1987  it  is  almost  certain  that  backbone  capacity  will 
be  increased.  Hence  delay  calculations  for  Phase  II  -  Scenario  II  would  not  be  particularly 
meaningful  and  are  not  included.  For  other  cases,  NADIN  network  delays  are  shown  in 
Table  4-2. 

NADIN  can  provide  adequate  service  to  RMMS  traffic  in  Phase  n  provided  the 
enhancements  in  port  speed  and  processor  capacity  discussed  in  Section  5  are  carried  out. 
The  average  delays  expected  for  a  typical  RMMS  message  from  Enroute  MPS  to  NADIN 
concentrator  to  NADIN  switch  to  NADIN  switch  to  a  NADIN  concentrator  to  Enroute  MPS 
are  listed  in  Table  4-3  under  various  loads. 

4.2.3  Long  Term  Performance 

The  long  term  impact  of  RMMS  and  the  national  Maintenance  Management  System  on 
NADIN  performance  is  difficult  to  quantify  at  this  point  in  the  development  of  these  two 
nascent  programs.  However,  it  is  apparent  that  additional  backbone  capacity  will  be  needed 
by  the  1990-92  time  frame  if  the  MMS  is  fully  implemented.  This  additional  capacity  might 
be  in  the  form  of  new  NADIN  backbone  links  for  higher  connectivity  or  increased  band  width 
on  existing  links. 

4.2.4  Sensitivity  to  Change  in  Traffic  Scenario 

The  scenarios  on  which  these  performance  values  are  based  were  those  projected  by 
the  RMMS  program  office  at  the  time  the  study  was  undertaken.  Changes  in  these  scenarios 
are  now  a  distinct  possibility  particularly  in  the  local  access  arrangements  for  the  RMS/MPS 
links.  However,  these  changes  to  the  RMMS  configuration  for  Phase  I  and  beyond  do  not 
impact  the  aggregate  RMMS  traffic  to  be  carried  by  the  NADIN  backbone  nor  the  aggregate 
locally  switched  traffic  at  the  NADIN  concentrator.  The  possible  changes  in  RMMS 
configuration  are  outlined  in  Section  D.5.  The  recommendations  and  findings  in  Section  5 
remain  valid  although  slight  changes  in  the  throughput/delay  results  for  the  Enroute 
MPS/NADIN  link  may  occur  under  the  possible  new  RMMS  configuration. 
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PERIOD 

AVG.  DELAY  (SEC) 
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RMMS  MSG 

NAOIN  IA 

Y 

1.57 
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N 

1.03 

.7 

Phase  I 

Y 

1.62 

1.29 

N 

1.07 
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E  MPS/NADIN  INTERFACE  SPEED 
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4.3  Comparison  of  Alternatives 


The  networking  approaches  defined  in  Section  3  are  compared  in  several  key  areas 
including: 

•  effectiveness  -  meeting  the  initial  communications  needs  of  RMMS  and  MMS, 

•  efficiency  -  the  efficient  use  of  NADIN  resources, 

•  timeliness  -  the  ability  to  implement  NADIN  support  in  a  time  frame  compatible 
with  RMMS  scheduling, 

•  RMMS  f.turity  -  the  ability  to  provide  for  future  communications  support  of 
RMMS,  and 

•  NADIN  futurity  -  the  ability  to  integrate  RMMS  driven  enhancements  of  NADIN 
with  other  planned  or  potential  enhancements  of  NADIN. 

These  items  are  discussed  in  subsequent  sections.  A  quantitative  summary  in  table 
form  of  these  and  related  factors  is  shown  in  Table  4-4. 

4.3.1  Effectiveness  for  Initial  Requirements 


All  four  of  the  alternatives  considered  will  meet  the  initial  communications  needs  of 
MPS  to  MPS  communications.  However,  if  large  file  updates  are  common  in  Phase  I  (not 
expected)  then  Alternative  4  will  provide  substantially  better  performance  than  any  of  the 
other  approaches  with  Alternative  2  providing  the  next  best  results.  Alternative  4  substan¬ 
tially  reduces  overhead  as  well  as  reducing  the  average  number  of  hops  from  origin  to 
destination.  Alternative  2  reduces  overhead  compared  to  Alternative  1  and  also  eliminates 
message  processing  at  the  switch  (DS  714)  as  does  Alternative  3. 


FACTORS 

ALT  1 

ALT  2 

ALT  3 

ALT  4 

NADIN  Hardware  Mods 

8 

6 

5 

2 

NADIN  Software  Mods 

8 

6 

6 

2 

RMMS  Hardware  Mods 

8 

7 

7 

6 

RMMS  Software  Mods 

5 

5 

9 

6 

Effective  Commn. 

4 

7 

7 

9 

Efficient  Use  of  NADIN 

2 

7 

6 

9 

Timeliness 

9 

7 

8 

1 

RMMS  Futurity 

2 

6 

9 

10 

NADIN  Futurity 

4 

6 

6 

10 

Scale:  1  =  highly  unfavorable  factor 

10  =  highly  favorable  factor 


TABLE  4-4:  COMPARISON  OF  ALTERNATIVES 
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4.3.2  Efficiency 


i 


This  criterion  sharply  differentiates  the  alternatives.  NADIN  was  designed  initially  to 
replace  a  variety  of  low-speed  teletype  circuits,  primarily  Area  B.  The  network  was 
conceived  as  a  value  added  message  switching  system  which  would  provide  code  and  speed 
conversions  as  well  as  format  editing  and  retrieval  of  accountable  traffic  for  non-intelligent 
terminals.  Alternative  1  is  a  continuation  of  this  approach.  However  the  MPSs  which 
control  RMMS  and  MMS  are  not  teletypes;  they  are  intelligent  host  computers  as  discussed 
in  Section  2.  MPS  traffic  does  not  require  message  processing  at  the  message  switch. 

In  Alternative  2  the  concentrator  does  not  need  to  look  into  the  text  of  MPS  messages 
and  build  a  NADIN  transport  header.  The  message  switch  does  not  need  to  build  the  network 
address  from  the  message  address.  Under  Alternative  2  the  MPS  dobs  all  these  things  with 
no  more  effort  on  its  part  than  message  preparation  in  Alternative  1.  1  x 

Alternatives  requires  the  NADIN  concentrator  to  build  a  transport  header  but  it 
should  be  possible  to  construct  the  header  primarily  based  on  the  MPS  supplied  packet 
header  and  implied  information  based  on  origin-destination.  Hence  Alternative  3  should 
reduce  message  processing  at  the  NADIN  concentrator. 

Alternatives  2,  3  and  4  eliminate  the  need  for  message  based  processing  of  MPS 
messages  by  the  DS  714s  and  reduce  by  at  least  one  the  number  of  hops  for  a  typical  frame. 
Of  course  those  messages  from  teletypes  and  other  sources  which  do  require  network 
services  will  continue  to  receive  them  at  the  NADIN  switching  centers  as  in  NADIN  IA. 

4.3.3  Timeliness 

The  Enroute  MPS  installation  plan  (Reference  8)  shows  complete  installation,  testing 
and  acceptance  of  all  23  Enroute  MPSs  (pius  one  at  Oklahoma  City)  by  calendar  year  1984. 
Since  NADIN  IA  is  not  scheduled  for  completion  until  the  third  quarter  of  calendar  year 
1983,  it  is  important  that  additional  delays  to  initiate  NADIN  support  of  MPS  to  MPS 
communication  be  kept  to  a  minimum.  It  is  this  criterion  which  makes  Alternative  4 
infeasible  for  the  short  term.  The  modifications,  both  software  and  hardware  (Section  4.1), 
needed  to  accomplish  Alternative  4  are  extensive,  involving  major  delays  and  need  for 
substantial  additional  funding.  The  costs  for  these  enhancements  are  being  addressed  by 
NAC  for  the  FAA  under-  this  contract,  Task  13. 


i 
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The  minimum  modification  and  hence  the  quickest  implementation  is  possible  under 
Alternative  1,  since  this  is  only  a  minor  extension  of  the  NADIN  IA  architecture,  primarily 
in  the  enhanced  local  switching. 

Alternative  2  would  require  more  time  to  implement  than  Alternative  1  but  involves 
no  new  hardware  or  communications  links.  The  software  changes  are  substantial  at  the 
concentrator  and  particularly  the  FEP  but  should  not  cause  a  major  delay  in  integrating 
RMMS  into  NADIN. 

Alternative  3  is  very  timely  from  the  RMMS  side.  It  will  be  easy  to  provide  an  X.25 
interface  for  the  MPSs  since  Tandem  has  an  off-the-shelf  X.25  package.  However,  the 
software  to  maintain  correspondence  between  MPS  initiated  virtual  circuits  and  network 
addressing  of  messages  would  be  considerable.  In  addition,  the  FEP  and  some  of  the 
concentrator  mods  of  Alternative  2  are  also  needed.  Preliminary  analysis  shows 
Alternatives  2  and  3  are  about  equal  here. 

4.3.4  Futurity  from  RMMS/MMS  Viewpoint 

It  is  essential  that  RMMS  and  MMS  communications  needs  for  MPS-MPS  traffic  be  met 
not  only  in  the  short  run  but  also  the  long  run.  In  the  same  vein  NADIN  planners  want  to 
ensure  network  users  that  their  future,  as  well  as  their  current  needs,  are  being  taken  into 
account.  From  this  perspective  Alternative  4  is  the  superior  approach.  In  the  late  1980s  it 
is  expected  that  the  Maintenance  Management  System  will  have  reached  a  high  level  of 
development  characterized  by  large  file  updates  and  file  transfers.  Interactive  traffic  will 
be  common  in  RMMS  by  then.  Hence  the  virtual  circuit  service  possible  in  Alternative  4 
will  be  of  great  benefit. 

None  of  the  other  three  alternatives  will  be  suitable  in  the  long  term.  However,  they 
differ  in  the  degree  to  which  they  hinder  or  aid  the  evolution  of  the  MPS/NADIN  system  to 
Alternative  4.  From  the  MPS  side,  Alternative  1  is  a  step  in  the  wrong  direction,  i.e.,  away 
from  packet  switching  and  computer-to-computer  communication.  Software  to  segment 
files  into  3700  character  messages  would  be  required  at  the  MPS.  Message  headers  would  be 
inserted.  Alternative  1  forces  the  MPS  to  emulate  a  dumb  terminal  which  is  not  desirable 
either  for  NADIN  or  for  the  RMMS/MMS  programs. 

Alternative  2  is  a  partial  step  in  the  direction  of  Alternative  4.  The  MPS  would  hand 
frames  to  NADIN  with  their  contents  transparent  to  the  network.  NADIN  handling  would  be 
frame  based  rather  than  message  based.  Long  files  would  be  packed  into  frames  by  the  MPS 
just  like  any  other  MPS  data. 
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Alternative  3  is  obviously  a  major  step  toward  the  total  packet  switched  approach  of 
Alternative  4.  From  the  RMMS  side  no  further  change  is  needed  to  achieve  virtual  circuit 
service.  This  is  a  very  strong  point  for  Alternative  3. 

4.3.5  Futurity  from  the  NADIN  Viewpoint 

It  appears  that  by  the  late  1980s  NADIN  will  evolve  into  a  packet-switched  network 
offering  X.25  interfaces,  virtual  circuits  and  datagram  service  to  users  such  as  NAS-NAS 
(Computer  B).  The  need  for  this  evolution  has  been  indicated  in  References  9  and  10  and  it 
is  expected  that  future  user  needs  will  add  to  this  requirement. 

In  light  of  this  trend,  Alternative  4  is  the  approach  with  the  most  NADIN  futurity. 
However,  it  is  possible  to  measure  the  other  three  approaches  against  this  criterion  also. 

Alternative  1  does  nothing  to  advance  the  trend  of  NADIN  to  become  more  than  a 
message-switched  network  designed  for  low-speed  terminals. 

Alternatives  2  and  3  make  a  small  step  toward  making  NADIN  a  network  suitable  for 
co mputer-to-co input er  communications.  However  the  software  changes  for  concentrator 
and  FEP  routing  to  accomplish  Alternatives  2  and  3  are  for  the  most  part  strictly  interim 
measures  and  are  not  useable  for  the  jump  to  Alternative  4. 

In  the  near  future  it  is  almost  certain  that  NADIN  will  be  serving  users  who  demand  an 
X.25  interface.  As  more  and  more  vendors  provide  off-the-shelf  X.25  packages  this  demand 
will  increase.  In  this  crucial  respect  Alternative  3  takes  an  important  step  toward  creating 
a  packet-switched  NADIN  network  responsive  to  future  user  needs. 

4.3.6  Overall  Comparison 

The  selected  alternative  must  be  effective,  efficient,  timely  and  provide  futurity  for 
both  RMMS  and  NADIN.  Based  on  the  analysis  above,  Alternative  3  is  overall  the  most 
feasible.  Implementation  schedules  rule  out  Alternative  4  although  for  the  long  term  it  is 
the  preferred  approach.  Alternative  1  is  not  appropriate  for  co  mputer-to-co  mputer 
communications  and  should  only  be  recommended  if  time  is  so  critical  that  no  time  is 
available  for  software  mods  at  the  concentrators  and  FEPs.  Alternative  2  offers  benefits  in 
performance  but  lack  of  futurity  weighs  heavily  against  it.  Table  4-4  shows  a  subjective 
assignment  of  weights  based  on  the  factors  discussed  in  Section  4.3. 


i 
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SECTION  5 


RECOMMENDATIONS 


5.  INTRODUCTION 

The  recommended  networking  approach  for  NADIN  support  of  RMMS  is  Alternative  3. 
This  approach  utilizes  the  current  NADIN  backbone  and  hardware  configuration.  Data  is 
presented  by  the  MPS  to  the  network  as  packets  across  an  X.25  interface. 

The  NADIN  concentrator  will  interpret  the  packet  header  and  for  non-local  traffic  will 
build  a  NADIN  transport  header  as  in  NADIN  IA  (Reference  5).  Local  traffic  can  be  routed 
by  the  concentrator  directly.  Non-local  traffic  is  forwarded  to  the  FEP  which  is  enhanced 
to  perform  routing.  RMMS  and  MMS  frames  are  routed  by  the  FEP  directly  to  their  network 
exit  point  (concentrator)  bypassing  the  message  processor  (DS  714)  at  the  switching  center. 
Other  NADIN  traffic  will  be  routed  to  the  message  processor  if  necessary  for 
accountability,  editing,  etc.  The  relation  of  protocol  layers  for  NADIN  IA  is  shown  in 
Figure  5-1.  The  relation  of  protocol  layers  for  the  MPS-NADIN-MPS  transfer  of  data  is 
shown  in  Figure  5-2. 

The  enhancements  to  NADIN  and  the  MPS/NADIN  interfaces  to  implement  this 
recommendation  are  discussed  in  this  section. 

5.1  Recommended  NADIN  Enhancements 


The  necessary  extensions  and  modifications  to  NADIN  are  primarily  in  the  FEP  and 
concentrator  software  although  ports  at  NADIN  concentrators  are  also  required.  The 
requirements  are: 

•  Concentrator  Hardware  and  Software  Modifications  -  to  support  X.25  physical, 
link  and  network  layers  and  to  provide  local  routing  capability. 

•  FEP  Software  Modifications  -  to  recognize  MPS  frames  and  perform  routing  of 
these  frames  based  on  concentrator  supplied  transport  header. 


PROTOCOL  LEVELS  IN  NADIN  IA 


•  Ports  -  initially  (1982-3)  one  additional  2400  b/s  port  at  each  concentrator  for 
Gnroute  MPS;  later  (1984-87)  an  average  of  four  additional  2400  b/s  ports  at  each 
concentrator  for  Sector  MPS.  Speeds  will  be  upgraded  as  needed  when 
significant  numbers  of  additional  RMSs  come  on  line  (after  1987). 

5.2  MPS/ NADIN  interface 

The  recommended  interface  includes  levels  one,  two  and  three  of  the  International 
Standards  Organization  (ISO)  seven  layer  model  (Figure  5-2).  Level  four  is  discussed  but  a 
detailed  recommendation  is  not  included  for  MPS  to  MPS  level  four  protocol.  The  major 
features  of  the  interface  are  summarized  below.  The  details  are  presented  in  Appendix  C: 
WPS/NADIN  ICD. 


The  Enroute  MPS  will  be  located  in  the  ARTCC.  The  channel  can  be  implemented  in  a 
direct  DTE-to-DTE  full  duplex  configuration  per  EIA  RS-449  (balanced)  standards.  Limited 
distance  modems  may  be  used  however.  The  communication  facility  will  be  twisted  pair 
cables.  Speed  will  be  2400  b/s. 

The  general  NAS  Sector  MPSs  are  remote  from  the  NADIN  concentrator.  They  will  be 
connected  by  full  duplex  leased  lines  (4  wire  conditioned  type  3002)  and  modems. 
Switchable  modems  capable  of  handling  full  duplex  synchronous  2400  or  4800  b/s 
transmissions  should  be  used  with  initial  speed  at  24Q0  b/s.  The  electrical/mechanical 
standard  is  again  EIA  RS-449  (balanced). 

This  physical  layer  is  capable  of  supporting  an  X.25  interface  to  NADIN  (Levels  2 
and  3)  without  electrical  modification.  For  open  system  interconnection  via  international 
common  carriers  X.25  calls  for  a  somewhat  different  mechanical  interface.  However,  the 
RS-449  mechanical  interface  is  easily  modified  to  be  X.25  compatible. 


5.2.2  Link  Layer  (ISO  Layer  2) 


The  Unk  level  procedure  will  be  ADCCP  as  described  in  Appendix  C.  Briefly  this  is  a 
two-way  simultaneous  non-switched  point-to-point  bit  oriented  protocol.  The  Balanced 
Asynchronous  (BA)  Mode  shall  be  used  with  each  station  acting  as  a  combined  (primary  and 
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secondary)  station.  Bit  stuffing  and  flags  are  used  to  achieve  code  and  byte  independent 
transmission.  Cyclic  Redundancy  Checks  (CRC)  are  used  for  error  control.  This  protocol 
with  the  balanced  mode  and  other  specifications  of  the  ICD  is  compatible  with  the  CCITT 
LAPB  protocol. 

5.2.3  Network  Layer  (ISO  Layer  3) 

The  X.25  packet  layer  or  network  layer  is  used  for  the  exchange  of  packets  between 
MPSs.  The  underlying  NADIN  network  will  not  use  X.25  internally  (until  such  time  in  the 
future  that  NADIN  evolves  to  a  packet-switched  network).  The  X.25  interface  provides 
virtual  circuits  and  datagram  service  to  the  MPS  which  NADIN  must  support  with  software 
modifications.  NADIN  internally  uses  a  transport  header  for  each  frame.  The  NADIN 
transport  header  provides  to  NADIN  some  of  the  end-to-end  transport  functions  such  as 
correct  sequencing  of  frames.  This  information  must  be  stored  by  the  NADIN  exit  point  and 
passed  across  the  X.25  interface  to  the  MPS  destination.  Special  software  at  the 
concentrators  will  be  needed  to  make  the  conversions  and  supply  the  packet  headers  to  the 
outbound  RMMS  packets/frames.  In  particular  additional  buffer  capacity  could  be  required 
to  store  frames  for  possible  resequencing. 

The  transport  layer  (ISO  Layer  4)  for  the  MPS  to  MPS  data  transfer  is  not  part  of  the 
ICD.  This  layer  is  discussed  in  Appendix  G.  Figure  5-3  shows  the  form  of  an  MPS  packet 
and  the  relationship  of  the  various  headers. 
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APPENDIX  A 


RMMS  OPERATION 


RMMS  operation  is  outlined  below  for  Phase  I  and  Phase  n  (Reference  8).  The 
operational  structure  of  RMMS  and  the  type  of  NADIN  support  needed  for  each  phase  are 
specified. 

A. I  RMMS  PHASE  I 


Phase  I  of  the  Remote  Maintenance  Monitoring  System  consists  of  the  enroute  or 
center  Maintenance  Processor  Subsystems  (MPS),  two  Remote  Monitoring  Subsystems 
(RMSs)  -  Remote  Center  Air  Ground  (RCAG)  RMS  and  Second  Generation  VORTAC  RMS, 
the  fixed  terminals  at  work  centers  and  technicians’  portable  terminals  and  those  portions  of 
the  Telecommunications  Network  (TCN),  including  NADIN,  required  to  service  them.  In  this 
section  the  role  to  be  played  by  NADIN  in  Phase  I  is  discussed  and  the  components  of  Phase  I 
are  defined. 

A. 1.1  MPS  to  MPS  Communication  in  Phase  I 

The  Enroute  MPS  in  each  enroute  area  will  carry  out  certification  reports,  maintain 
parameter  data  and  respond  to  alarm  signals  from  the  various  RMSs.  In  addition,  the 
Enroute  MPS  serves  as  the  information  source  for  the  work  center  fixed  terminals  and  to 
some  extent  for  the  portable  terminals.  In  particular,  facility  alarms  are  forwarded  by  an 
Enroute  MPS  to  the  responsible  work  center  and  its  associated  Sector  Office.  Herein  lies 
the  first  major  need  for  inter-area  MPS  to  MPS  communication. 

Many  of  the  approximately  80  Airway  Facility  Sectors  include  portions  of  two  or  more 
Air  Traffic  (AT)  enroute  areas.  Therefore,  a  facility  such  as  an  RCAG  or  VORTAC  lies  in 
one  AT  enroute  area  while  the  Sector  Office  for  that  AF  sector  is  located  in  an  adjacent  AT 
enroute  area.  The  work  center  responsible  for  the  facility  would  typically  be  in  the  same 
enroute  area  as  the  facility  site  but  even  this  may  not  always  be  the  case.  Hence,  it  is 
necessary  for  alarms  and  other  information  originating  at  or  destined  to  a  facility  RMS  to 


pass  from  one  Cnroute  MPS  to  another  adjacent  Enroute  MPS.  It  is  planned  (Reference  ?) 
that  NADIN  will  perform  this  communication  function.  Figure  A-l  illustrates  the 
overlapping  sector  phenomenon  as  well  as  the  NADIN  interconnection  for  MPS  to  MPS 
traffic.  Table  A-l,  based  on  data  in  Reference  18,  lists  the  work  centers  which  under 
current  sector  boundaries  will  report  to  Sector  Offices  outside  the  work  center's  enroute 
area. 

A. 1.2  Data  Base  Locations  in  Phase  1  RMMS 

Each  Enroute  MPS  will  maintain  status,  alarm,  certification  and  other  data  on  each  of 
the  RMS  monitored  facilities  and  work  centers  within  its  enroute  area's  boundary.  In 
addition,  each  MPS  will  maintain  a  copy  of  the  data  concerning  any  facilities  or  work 
centers  which  are  located  in  an  adjacent  enroute  area  but  are  associated  with  a  Sector 
Office  in  the  given  MPS's  area.  Referring  to  Figure  A-l,  both  "MPS  #1"  and  "MPS  #2"  will 
maintain  essentially  identical  files  of  Facility  "F"  data.  Inquiries  from  the  Sector  Office 
concerning  Facility  "F"  in  Figure  A-l  would  normally  be  answered  by  MPS  #1  from  its 
Facility  "F"  data  without  the  need  to  go  back  to  MPS  #2. 

A. 1.3  Regional  and  National  Data  Access  in  Phase  I 

Headquarters  Washington,  Regional  Headquarters,  National  Support  Group  and  possibly 
others  will  from  time  to  time  require  access  to  data  at  Enroute  MPSs.  In  Phase  I  RMMS, 
they  will  access  this  data  via  a  dial-up  connection  either  through  FTS  or  the  public  network 
but  not  via  NADIN.  This  is  one  of  the  features  that  distinguishes  Phase  I  implementation 
from  Phase  II  in  which  such  access  to  local  data  bases  will  be  via  NADIN. 

A.2  RMMS  Phase  H 

Phase  II  of  RMMS  is  defined  precisely  in  Section  2.3.  It  includes,  in  addition  to 
Phase  I,  the  approximately  80  General  NAS  Sector  MPSs,  some  features  of  the  Maintenance 
Management  System,  and  the  candidate  RMSs  described  in  Section  2.3.3  such  as  ARSR, 
RML,  ASR  and  others. 
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TABLE  A-l :  WORK  CENTERS  WITH  SECTOR  OFFICE  IN  ADJACENT  ENROUTE  AREA 


A. 2.1  Location  of  Data  Bases  in  Phase  n 

One  of  the  main  features  of  the  Maintenance  Management  Subsystem  and  Phase  0  of 
RMMS  in  general  is  the  maintenance  of  a  distributed  data  base.  National,  regional  and 
sector  levels  will  all  have  corresponding  data  levels.  The  creation  of  one  or  more  national 
Maintenance  Management  processors  as  well  as  possible  locations  have  not  yet  been 
determined  at  this  writing.  However,  it  is  planned  that  the  national  data  base  will  contain 
summary  information,  trend  analysis,  logistics  and  training  data,  trouble  shooting  data  and 
other  material  useful  for  national  planning  and  management. 

Each  AF  region  will  contain  a  regional  Maintenance  Processor  Subsystem  which 
probably  will  be  a  designated  Enroute  MPS  although  this  decision  is  not  yet  finalized.  The 
regional  MPS  will  collect  and  store  data  relevant  to  that  region^  operation.  Examples  are 
regional  summaries  of  equipment  performance,  modification  records,  trouble  shooting  data, 
equipment  inventory,  logistics  inventory  and  others.  This  regional  data  is  available  to  the 
national  MMS  for  concatenation  into  national  summaries. 

The  80  General  NAS  Sector  MPSs  or  possibly  the  Enroute  MPSs  will  be  responsible  for 
storage  of  all  data  related  to  the  individual  RMS  facilities,  work  centers  and  personnel  in 
their  sectors.  Certification  reports,  alarm  reports,  actions  taken  in  response  to  alarms, 
outage  records,  watch  schedules  and  other  data,  especially  that  required  on  a  day-to-day 
basis  at  the  sector  central  maintenance  facility  level,  will  be  stored  locally.  It  is  this  local 
data  from  the  various  sector  MPSs  which  the  regional  MPS  uses  to  compile  regional  files 
which  in  turn  are  used  for  national  analysis  by  the  national  MMS. 

A.2.2  Role  of  the  Enroute  MPS  in  Phase  11 

Original  plans  for  Phase  n  of  the  RMMS  called  for  the  Enroute  MPS  located  at  each 
ARTCC  to  be  the  hub  of  all  monitoring,  alarm  notification  and  system  interconnection.  All 
certification  reports,  alarms,  status  messages  and  uplink  commands  were  to  be  processed  at 
the  Enroute  MPS.  This  plan  has  been  modified.  Current  plans  are  for  the  Sector  MPS  to  act 
as  the  hub  for  most  but  not  all  monitoring  and  alarm  notification  in  its  sector.  Notification 
of  alarms  are  sent  by  the  Enroute  MPS  or  Sector  MPS  to  responsible  technicians  at  a  work 
center.  In  addition,  notice  of  the  alarm  is  also  sent  by  the  responsible  MPS  to  the  Sector 
MPS  or  Enroute  MPS  in  whose  boundary  the  alarmed  facility  is  located,  even  when  in  some 
cases  this  Sector  Office  or  ARTCC  may  be  in  an  adjacent  enroute  area. 
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A. 2. 3  Data  Access  and  Addressing  Responsibility  in  Phase  n 


One  of  the  major  objectives  of  the  national  MMS  program  is  to  provide  access  for 
national,  regional,  sector  and  local  technicians’  terminals  to  any  required  RMMT  date. 
Balancing  this  objective  is  the  requirement  to  conserve  communication  costs  and  protect  the 
system  from  overloading  and  abuse.  Therefore,  a  hierarchical  access  is  planned.  This  means 
that  data  requests  should  be  satisfied  routinely  by  the  data  base  logically  nearest  to  the 
requesting  level. 

A  request  originating  at  National  Headquarters  will  normally  be  satisfied  by  query  of 
the  national  MMS  data  bases,  similarly  for  regional  requests  and  so  on.  A  local  technician, 
for  example,  will  request  information  on  a  facility’s  status  or  repair  record  from  his  Sector 
MPS  through  the  Enroute  MPS.  Access  to  data  beyond  a  requestor^  logical  Aevel  or  physical 
sector  is  to  be  handled  in  the  following  manner.  First,  availability  of  data  to  an  individual 
will  be  regulated  by  the  authorization  level  of  that  individual  and/or  terminal.  Secondly, 
assuming  proper  authorization,  a  requestor  may  obtain  data  from  a  remote  site  in  two  ways. 
The  requestor  may  simply  forward  his  request  to  the  appropriate  Enroute  MPS  <via  NADIN  if 
this  MPS  is  outside  his  area)!.  The  Enroute  MPS  will  accept  the  request  and  solicit  the 
requested  information  from  the  appropriate  data  location,  typically  a  Sector  MPS.  This  data 
will  be  what  is  currently  available  and  will  not  result  in  facility  polling.  Alternatively,  the 
requestor  may  supply  the  complete  address  of  the  remote  site  to  NADIN  which  will  pass  it 
through  the  appropriate  Enroute  MPS  for  forwarding  to  the  remote  RMS.  In  this  way  the 
requestor  can  obtain  essentially  real  time  data  rather  than  the  currently  available  report 
stored  in  the  Sector  MPS. 


APPENDIX  B 


RMMS  FACILITIES  (PHASE  I) 

B.l  Phase  I  Environment 

Terminals,  processors,  monitoring  subsystems  and  their  associated  circuits  in  Phase  I 
RMMS  are  described  in  this  section. 

B.1.1  Enroute  MPS 


Program  plans  (Reference  8)  call  for  delivery  of  twenty  four  (plus  one  optional) 
Enroute  MPSs  to  be  located  at  the  twenty  three  Air  Route  Traffic  Control  Centers  plus 
Oklahoma  City  with  an  option  for  Atlantic  City.  Delivery  begins  January  1982  and  will  be 
completed  December,  1983  as  shown  in  Table  B-l.  Testing  of  the  processors  is  to  be 
completed  as  of  March,  1984. 

In  Phase  I  Enroute  MPSs  will  interface  with: 

•  RCAG  RMS  Type  I  and  Type  H, 

•  VORTAC  Remote  Monitoring  Equipment  (plans  for  using  RMC-C  at  ARTCC  have 
been  dropped) 

•  work  center  fixed  terminal  output  subnet 

•  portable  terminals  via  dial  up 

•  NADIN  concentrator  collocated  at  each  center,  and 

•  Flight  Service  Data  Processing  System  (FSDPS). 


DELIVERY 

NUMBER 

SITE 

DELIVERY 

DATE 

TEST 

COMPLETION 

DATE 

1 

Site  1  Oklahoma  City** 

1  Jan  1982 

9  Apr  1982 

2 

Site  2  Kansas  City 

22  Feb  1982 

21  May  1982 

3 

Site  3  Los  Angeles 

5  Apr  1982 

2  Jul  1982 

4 

Site  4  Anchorage 

10  May  1982 

13  Aug  1982 

5 

Site  5  Chicago 

21  Jun  1982 

24  Sep  1982 

6 

Site  6  Atlanta 

9  Aug  1982 

5  Nov  1982 

7 

Site  7  Fort  Worth 

6  Sep  1982 

3  Dec  1982 

8 

Site  8  San  Juan 

11  Oct  1982 

7  Jan  1983 

9 

Site  9  Houston 

8  Nov  1982 

4  Feb  1983 

10 

Site  10  Jacksonville 

6  Dec  1982 

4  Mar  1983 

11 

Site  11  Albuquerque 

3  Jan  1983 

1  Apr  1983 

12 

Site  12  Miami 

31  Jan  1983 

29  Apr  1983 

13 

Site  13  Oakland 

28  Feb  1983 

27  May  1983 

14 

Site  14  Memphis 

21  Mar  1983 

24  Jun  1983 

15 

Site  15  Seattle 

25  Apr  1983 

22  Jul  1983 

16 

Site  16  Honolulu 

23  May  1983 

19  Aug  1983 

17 

Site  17  Salt  Lake 

13  Jun  1983 

16  Sep  1983 

18 

Site  18  Denver 

18  Jul  1983 

14  Oct  1983 

19 

Site  19  Indianapolis 

15  Aug  1983 

11  Nov  1983 

20 

Site  20  Minneapolis 

12  Sep  1983 

9  Dec  1983 

21 

Site  21  Cleveland 

10  Oct  1983 

6  Jan  1984 

22 

Site  22  Washington 

7  Nov  1983 

3  Feb  1984 

23 

Site  23  New  York 

5  Dec  1983 

3  Mar  1984 

24 

Site  24  Boston* 

26  Dec  1983 

31  Mar  1984 

25 

Option  Atlantic  City 

TBD 

*  Factory  Test  unit  reinstalled 

**  Tandem  equipment  delivery  dates  to  be  three  months  earlier 


Source:  Reference  8 


TABLE  B-l:  ENROUTE  MPS  DELIVERY  SCHEDULE 
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Of  these  interfaces,  those  that  have  been  defined  are: 


•  RCAG  RMS  Type  I  and  II  -  110  bit/sec  4  wire  half  duplex  data  over  voice  using 
American  National  Standards  Institute  (ANSI)  X  3.28  point-to-point  subcategory 
2.5  alternate  two  way  link  protocol  (References  1  and  16), 

•  VORTAC  -  1200  b/s  data  transmission  using  a  speech  plus  data  arrangement 
over  voice  grade  lines  with  Advanced  Data  Communications  Control  Procedure 
(ADCCP)  link  protocol  (References  1  and  19),  and 

•  Work  center  output  subnet  -  where  needed  medium  speed  connections  using 
ADCCP  link  protocol  (access  arrangements  are  still  under  design).  Other  sites 
will  utilize  300  b/s  dial-up  access. 

The  NADIN/RMMS  interface  is  addressed  in  this  report  (Sections  2  and  5  and 
Appendix  H). 

B.1.2  RCAG  RMS  Units 


There  will  be  a  total  of  414  RCAG  RMS  units  in  Phase  I  including  Type  I  and  Type  II 
scattered  through  23  enroute  areas.  An  additional  117  RCAG  RMSs  are  expected  to  be 
added,  bringing  the  total  to  approximately  531.  Each  Type  n  RCAG  is  collocated  at  an 
ARTCC  with  an  Enroute  MPS.  Up  to  40  Type  I  RCAGs  feed  into  a  Type  II  unit  where  voice 
is  stripped  and  data  passed  to  the  MPS.  Each  Type  I  unit  corresponds  to  a  separate  output 
port  at  the  MPS  to  the  Type  II  unit  (Reference  2).  Polling  of  Type  I  and  II  units  is  carried 
out  by  the  Enroute  MPS.  Implementation  is  scheduled  over  the  period  1982-1983  as  shown  in 
Table  B-2.  Each  RCAG  Type  I  and  II  is  connected  to  the  MPS  via  point-to-point  links  as 
described  in  Section  B.1.1. 

B.1.3  VORTAC  RMS  Equipment 

There  are  approximately  906  Facility  Central  Processing  Units  (FCPUs)  located  at 
sites  which  contain  VOR,  TACAN,  DME  and  support  equipment.  The  FCPU  polls  equipment 
monitors  which  obtain  parameter  values  measuring  the  conditions  of  the  VOR,  TACAN  and 
DME  equipment  as  well  as  environmental  data.  The  FCPUs*  local  access  to  the  Enroute  MPS 
is  now  under  revision.  At  some  field  locations  such  as  Sector  Offices  in  the  busiest  sectors, 
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the  FCPUs  may  be  polled  and  controlled  by  a  communication  controller  device  which  will 
interface  via  leased  lines  or  possibly  dial-up  to  the  Enroute  MPS  or  eventually  the  Sector 
MPS.  At  less  busy  locations  the  FCPUs  may  utilize  dial-up  connections  direct  to  the 
Enroute  and/or  Sector  MPS  to  report  alarm  conditions.  Certification  action  at  such  sites 
would  be  initiated  by  dial-out  from  the  MPS.  These  issues  are  still  under  study  by  FAA  at 
this  time.  As  shown  in  Table  B-2,  implementation  of  the  second  generation  VORTAC 
equipment  is  scheduled  to  occur  incrementally  over  the  period  1981  to  1984. 

B.1.4  Terminals 

Phase  I  RMMS  utilizes  both  fixed  and  portable  terminals.  Fixed  terminals  will  be 
located  at  240  work  centers  (WC).  Examples  of  least  cost  circuit  configurations  for  leased 
lines  are  shown  in  Reference  18.  These  fixed  terminals  will  form  a  subnetwork,  some  of 
which  will  utilize  2400  bit/sec  multipoint  lines  using  a  four  wire  full  duplex  mode  with  an 
ADCCP  link  protocol.  Other  WCs  will  use  dial-up  to  the  MPS.  The  Enroute  MPS  will 
maintain  a  list  of  work  centers  responsible  for  each  monitored  facility.  When  an  alarm 
occurs,  these  responsible  technicians  will  be  notified  via  the  fixed  terminal  output  subnet. 

Portable  terminals  will  be  provided  to  technicians  travelling  to  remote  sites  for 
maintenance  or  inspection.  These  terminals  can  be  used  in  two  different  modes.  First  a 
terminal  can  be  connected  on-site  to  query  the  local  RMS  directly  for  status  and  parameter 
information.  However,  if  further  information  is  needed  or  if  data  about  a  remote  site  is 
required  then  the  portable  terminal  can  access  the  Enroute  MPS  via  a  dial  up  connection. 
The  number  of  portable  terminals  on  line  at  any  given  time  should  strongly  correlate  with 
on-site  trips  by  service  technicians.  The  traffic  generated  by  these  visits  is  discussed  in 
Appendix  C. 

Washington  Headquarters,  Regional  Headquarters  and  possibly  other  locations  will  be 
equipped  with  terminals  which  can  access  data  at  Enroute  MPSs  via  dial  up  connection.  The 
precise  number  of  these  terminals  has  not  yet  been  determined  and  many  may  not  be 
implemented  until  Phase  n. 
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COMMISSIONING 


RMMS  COMMISSIONING  SCHEDULE 
(1981-1984) 


Numbers  of  RMS  Units 

Year 

VOR 

VORTAC 

ARSR 

RCAG 

MPS  at 

ARTCC 

Single 

Dual 

Single 

Dual 

LRR 

ATCBI 

1 

- 

- 

n 

81 

- 

- 

- 

- 

Kfl 

144 

- 

116 

6 

50 

20 

109 

- 

20 

298 

13 

1984 

73 

55 

IH 

- 

23 

- 

- 

4 

TOTALS 

123 

75 

354 

354 

23 

20 

414 

23 

Source:  Reference  8 


TABLE  B-2:  RMMS  COMMISSIONING  SCHEDULE 


APPENDIX  C 


RMMS  TRAFFIC 


The  heart  of  a  data  communications  requirements  analysis  is  the  compilation  of  the 
traffic  loading  which  must  be  served  by  the  utility.  In  this  appendix,  the  message  types, 
their  length  characteristics,  arrival  characteristics,  their  sources,  sinks  and  other  essential 
features  are  discussed.  Traffic  is  described  in  detail  for  Phase  I.  However,  Phase  n  RMMS 
traffic  is  expected  to  consist  of  the  same  message  types. 

C.l  MESSAGE  TYPES 


The  RMMS  will  transmit  17  types  of  messages  which  will  require  NADIN  handling  in 
Phase  1.  These  are  discussed  briefly  below  grouped  into  four  message  categories. 

C.1.1  Alarm  Messages 

Whenever  an  alarm  condition  is  detected  by  an  RMS  and  after  appropriate  pre-alarm 
filtering,  an  alarm  message  is  forwarded  to  the  Enroute  MPS.  A  notification  is  then  sent  by 
the  MPS  to  the  responsible  work  center  and  appropriate  Sector  Offices  provided  the  time  of 
day  is  a  manned  period  for  that  office.  When  the  alarm  condition  is  corrected,  the  work 
center  notifies  the  Enroute  MPS.  However,  if  the  MPS  itself  notes  that  the  alarm  condition 
no  longer  exists,  it  will  notify  the  appropriate  work  centers  or  other  terminals.  Altogether 
the  alarm  process  involves  a  total  of  five  message  types: 

Alarm  Message  (AM)  -  notification  that  particular  parameter  at  indicated  site  has 
exceeded  alarm  threshold. 

Alarm  End  (AE)  -  notification  by  MPS  to  appropriate  terminals  that  alarm  condition 
no  longer  exists. 

Alarm  Delete  (AD)  -  notification  by  technician  that  alarm  condition  has  been 
corrected. 
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Alarm  Disable  (DA)  -  request  by  technician  or  responsible  Sector  Office  to  MPS 
advising  that  particular  alarms  are  to  be  ignored. 

Alarm  Threshold  Change  (TC)  -  request  by  authorized  personnel  that  MPS  tempo¬ 
rarily  change  RMS  alarm  threshold. 

C.1.2  Certification 

Service  certification  will  be  accomplished  by  the  MPS  on  a  scheduled  basis  or  as 
requested  by  authorized  technicians.  This  certification  will  involve  the  comparing  of 
"certification  parameters"  received  from  the  RMS  with  specified  parameter  values.  This 
process  will  become  a  major  part  of  the  legal  certification  process  but  will  not  replace 
human  decision  authority.  The  three  message  types  associated  with  certification  are: 

Certification  Report  (CR)  -  Response  by  RMS  to  a  scheduled  poll  requesting  full  or 
partial  certification  data.  These  messages  employ  highly  structured  format 
(References  1,  16,  19  and  20)  to  achieve  data  compression. 

Certification  Request  (CQ)  -  Request  by  MPS  for  certification  data  from  RMS. 
Varies  with  type  of  RMS,  i.e.,  RCAG  vs.  VORTAC. 

Certification  History  (CH)  -  Information  from  previous  certification  reports  and/or 
the  logging  data  concerning  the  collection  of  those  reports. 

Certification  History  Request  (CHQ)  -  Request  for  information  from  previous  certifi¬ 
cation  reports  and/or  data  concerning  collection  of  these  reports. 

C.1.3  Status  Messages 

The  Remote  Monitoring  Subsystem  status  message  provides  information  on  the 
condition  of  the  RMS  and  its  peripherals.  Such  messages  can  be  generated  in  response  to 
requests  from  the  MPS,  from  Airway  Facilities  personnel  via  terminals  or  in  the  case  of 
VORTAC  RMS,  automatically  in  response  to  a  continuous  poll  when  the  system  detects  a 
problem  with  itself.  The  level  of  detail  in  the  status  report  will  vary  depending  on  the  type 


of  RMS  and  on  the  method  of  generation.  In  Phase  I  RMMS  there  are  six  types  of  messages 
associated  with  status  reporting: 

VORTAC  Status  Condition  (VSC)  -  Brief  synopsis  of  status  condition  in  each  of  four 
monitor  elements;  VOR,  TACAN,  DME  and  environmental  in  response  to  continuous 
polling. 

VORTAC  Status  Reply  (VSR)  -  Listing  of  all  parameter  values  associated  with 
requested  monitor(s).  Single  parameter  values  can  not  be  obtained  except  with  entire 
set  of  monitor’s  data. 

VORTAC  Status  Request  (V5Q)  -  Uplink  servo  command  to  one  or  more  of  the  four 
VORTAC  elements  for  status  report. 

RCAG  Status  Reply  (RSR)  -  Report  of  single  parameter  or  group  of  parameters  in 
response  to  request  by  MPS  or  by  locally  connected  technician. 

RCAG  Status  Summary  (RSQ)  -  Uplink  command  by  MPS  to  send  one  or  more 
parameters  of  one  or  more  RCAG  subelements  (channels,  etc.),  usually  generated  by 
MPS  in  response  to  an  alarm  notification. 

RCAG  Status  Summary  (RSS)  -  Summary  of  equipment  status  as  currently  stored  at 
MPS. 

C.1.4  Terminal  Messages 

In  addition  to  the  message  types  mentioned  above,  technicians  may  input  and  exchange 
free  format  English  language  messages  via  fixed  or  portable  terminals. 

Teletype  or  Free-Format  Messages  (TTY)  -  Messages  in  free  format  English  to  or 
from  a  terminal. 


C.1.5  Miscellaneous  Messages 


Occasionally  other  messages  will  be  transmitted  in  the  RMMS.  These  shall  be 
collectively  referred  to  as: 

Administrative  Messages  (ADM)  -  Generally  related  to  network  operation  or  simply 
general  information. 

C.2  MESSAGE  CHARACTERISTICS 


In  this  section,  message  lengths  and  frequencies  are  discussed  for  Phase  I  RMMS.  The 
figures  presented  represent  best  estimates  based  on  current  implementation  philosophy  as 
outlined  in  References  1,  2,  7,  8,  19  and  20.  In  addition,  interpretations  and  verbal  updates 
from  AAF  450  personnel  have  been  reflected.  Precise  values  will  probably  change  as 
implementation  proceeds.  However,  for  initial  design  purposes  the  values  contained  in  this 
section  are  sufficiently  firm. 

C.2.1  Message  Lengths 

The  lengths  of  the  various  messages  discussed  in  Section  C.l  are  shown  in  Table  C-l. 
Since  most  of  these  message  formats  have  not  yet  been  completely  specified  between  RMS 
and  MPS  the  lengths  shown  for  MPS  to  MPS  traffic  represent  best  estimates.  In  particular, 
certification  report  formats  have  not  been  finalized  at  this  writing  by  the  RMMS  program. 
Various  block  sizes  are  being  considered  especially  for  the  scheduled  certification  reports 
with  an  eye  to  prevent  the  longer  but  lower  priority  certification  message  from  delaying 
short  but  high  priority  alarm  and  status  messages.  The  certification  report  (CR)  length 
shown  in  Table  C-l  is  the  entire  message  not  a  single  block  of  the  certification  report.  That 
is,  the  CR  includes  the  parameter  values  for  all  subelements,  e.g.,  channels,  environmental 
and  common  at  an  RCAG.  The  individual  parameter  groups  will  be  transmitted  from  RMS  to 
MPS  as  blocks  of  an  as  yet  undetermined  size  and  may  even  be  treated  by  the  lowest  three 
protocol  layers  as  separate  messages.  But  the  MPS  will  treat  these  parameter  group  blocks 
as  part  of  the  same  certification  report.  It  is  on  this  basis  that  certification  reports  and 
related  messages  are  sized  in  Table  C-l. 


One  assumption  regarding  the  contents  of  certification  reports  is  made.  It  is  assumed 
that  alarm  threshold  levels  are  to  be  included  and  may  vary  with  each  occurence  of  that 
parameter  at  a  different  subelement.  For  example,  Channel  1  and  Channel  2  at  an  RCAG 
facility  may  have  different  alarm  thresholds  specified  which  will  both  be  reported  in  the 
certification  report. 

C.2.2  Message  Frequency 

Traffic  load  in  RMMS  Phase  I  from  MPS  to  MPS  which  is  to  be  supported  by  NADIN  is 
presented  in  this  section.  Tables  C-2  and  C-3  show  the  heaviest  loading  projected  for  a 
NADIN  concentrator  due  to  MPS  traffic  for  normal  and  extreme  foul  weather  respectively. 
These  estimates  are  based  on  RCAG  and  VORTAC  Specifications  (References  7,  17  and  18) 
plus  discussions  with  program  personnel.  The  concentrator  load  consists  of  the  sum  of  all 
RMMS  traffic  to  or  from  the  collocated  Enroute  MPS.  Several  steps  are  used  to  derive  the 
results  in  Tables  C-2  and  C-3: 

•  the  traffic  is  assumed  uniform  for  each  type  of  facility,  i.e.,  each  6  channel 
RC  AG,  etc., 

•  to  obtain  an  upper  bound  on  traffic,  the  number  of  facilities  per  work  center  is 
assumed  equal  to  twice  the  average,  i.e.,  6  RCAG  RMS  and  8  VORTAC  RMS  per 
work  center. 

•  the  maximum  traffic  occurs  at  concentrators  in  the  ZHU  and  ZFW  areas,  each  of 
which  have  a  combined  total  of  four  work  centers  which  exchange  information 
with  remote  Sector  Offices. 

Of  this  data,  the  greatest  uncertainty  relates  of  course  to  the  frequency  of  alarm 
occurences.  Since  in  many  cases  the  equipment  being  monitored  will  be  new  solid  state 
hardware,  the  predicted  alarm  rates  are  subject  to  revision  as  experience  with  the  system  is 
acquired. 

To  compute  maximum  one  direction  link  flow  due  to  Phase  I  RMMS  from  MPS  to 
NADIN  concentrator  or  reverse,  the  total  node  traffic  shown  in  Tables  C-2  and  C-3  is 
multiplied  by  the  factor  L  =  0.75, 


C-6 


TYPE 

MSG/HR 

KB/SEC 

COMMENTS 

RCAG  CR 

24 

.02 

VORTAC  CR 

32 

.044 

Assumes  all  VORTAC  certifications 
in  same  hour 

RCAG  AM 

1/4 

.00001 

Based  on  one  alarm/site/4  days 

i 

VORTAC  AM 

1/5 

.000014 

One  alarm/site/week 

RCAG  AE 

1/4 

.000012 

VOR  AE 

1/5 

.000014 

VOR  DA 

1/5 

.000012 

RCAG  DA 

1/4 

.000014 

|  TC 

2/5 

.000024 

VOR  CH 

1/30 

.0001 

once/month 

RCAG  CH 

1/25 

.00008 

once/month 

CHQ 

2/27 

.000006 

VSR 

1/5 

.00006 

VSQ 

1/5 

.000012 

RSR 

1/4 

.00004 

i  RSQ 

• 

1/4 

.00001 

FFM 

2/13 

.00004 

Assume  30%  of  alarms  result  in 
site  visit 

ADM 

2 

.0006 

TOTAL 


TABLE  C-2:  MAXIMUM  NORMAL  RMMS  TRAFFIC  AT  NADIN 
CONCENTRATOR  (PHASE  I) 


TYPE 

MSG/HR 

KB/SEC 

RCAG  CR 

24 

.02 

VORTAC  CR 

32 

.044 

RCAG  AM 

48 

.002 

VORTAC  AM 

64 

.006 

RCAG  AE 

48 

.002 

VOR  AE 

64 

.004 

VOR  DA 

64 

.004 

RCAG  DA 

48 

.004 

TC 

2 

.0002 

VOR  CH 

1/30 

.0002 

RCAG  CH 

1/25 

.0002 

CHQ 

2/27 

‘  ■ 

.000002 

VSR 

64  | 

.014 

VSQ 

64 

.004 

RSR 

48 

.008 

RSQ 

48 

.002 

FFM 

56 

.01 

COMMENT 


2  alarms/s 
2  alarms/s 


One  visit, 


ADM 


14 


004 
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GROSS  THROUGHPUT 

Gross  throughputs  are  calculated  in  this  appendix  both  for  the  NADIN  backbone  links 
and  for  the  RMMS/NADIN  interfaces.  Traffic  levels  are  developed  for  four  periods: 

•  NADIN  Level  I A  -  based  on  the  net  throughput  contained  in  Table  Z-9, 
Appendix  Z  of  the  NADIN  Specification  (Reference  4). 

e  Phase  I  RMMS  plus  NADIN  IA  -  based  on  the  net  throughput  for  Phase  I  RMMS 
described  in  Appendix  C. 

•  Phase  n  Scenarib  1  RMMS  -  described  in  Section  D.4. 

•  .  1 

•  Phase  n  Scenario  n  RMMS  -  described  in  Section  D.4.  ;  1 1 
D.l  GROSS  THROUGHPUT  MODEL 

Peak-period  throughput  requirements,  measured  in  bits  per  second  (b/s),  have  been 
determined  for  each  link.  The  requirements  have  been  calculated  in  two  forms: 

•  Net  throughput  (NT)  -  the  bits  representing  original  messages  that  are  to  be 
transmitted  per  second,  and 

•  Gross  throughput  (GT)  -  the  total  number  of  bits,  including  all  overhead 
transmissions,  that  are  to  be  transmitted  per  second. 

Both  requirements  are  calculated  from  the  average  message  length  (L,  measured  in 
characters  per  message)  and  the  peak-period  message  frequency  (F,  measured  in  messages 
per  hour).  Net  throughput  is  the  product  of  these  two  message  characteristics,  with 
appropriate  conversion  of  units,  i.e.: 


NT 


FxLxB/S 


where  B  =  8  =  the  number  of  bits  per  character, 

S  =  3600  =  the  number  of  seconds  per  hour. 

Thus: 


NT  =  .002222  xFxL 

Gross  throughput  reflects  the  addition  of  all  other  bit,  character  and  message 
transmissions  required  by  the  network  (NADIN)  or  link  (ADCCP)  protocols.  These  have  been 
detailed  in  the  Level  IA  Study  (Reference  13)  and  are  summarized  below: 

•  NADIN  requires  a  header  and  trailer  on  each  "message”.  Together  these  involve 
approximately  63  characters.  A  NADIN  message  is  limited  to  3700  characters. 
Thus,  any  actual  message  or  file  which  contains  more  than  3700  characters  must 
be  broken  down  into  two  or  more  NADIN  messages,  with  a  header  and  trailer 
added  to  each. 

•  Messages  are  transmitted  across  the  individual  NADIN  backbone  links  in  frames 
with  245  or  fewer  characters.  ADCCP  adds  frame  control  data,  equivalent  to 
11  characters  for  each  frame,  and  inserts  additional  zero  bits  to  avoid  ambiguity 
between  data  and  synchronization  bit  strings.  It  has  been  determined  that  the 
zero  insertion  process  increases  the  number  of  bits  (and  hence  the  number  of 
equivalent  characters)  by  about  1.6  percent. 

•  Both  the  network  and  link  protocols  transmit  control  messages  on  the  lines.  It 
has  been  estimated  that  each  adds  the  equivalent  of  3  percent  to  the 
transmissions. 

•  Finally,  the  control  procedures  cause  the  automatic  retransmission  of  frames 
containing  transmission  errors.  It  has  been  conservatively  estimated  that 
2.b  percent  of  all  frames  must  be  retransmitted. 
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Taking  these  overhead  items  into  consideration,  the  gross  message  length  (QL)  and 
gross  message  frequency  (GF)  are  determined  froms 

GL  =  £l  +  (a  x  63)  +  (b  x  11)]  x  1.016 

where  a  =  the  smallest  integer  ^L/3?00, 

b  =  the  smallest  integer  +  (a  x  63)]  /2 45 . 

GF  =  F  x  1.03  x  1.03  x  1.025 

1.087  x  F. 


The  gross  throughput  is  calculated  as: 


GT  =  GF  x  GL  x  B/S 

=  .00245  F  x  [b  +  (a  x  63)  +  (b  x  11)] 

The  message  characteristics  and  associated  throughput  requirements  for  the  four 
stages  considered  are  presented  in  the  following  sections. 


D.2  NADIN  IA  TRAFFIC 


The  traffic  shown  in  Table  Z-9  of  the  liADHN  Specifications  (Reference  4)  is  net 
traffic.  These  figures  are  used  together  with  the  overhead  model  from  Section  D.l  to  derive 
the  throughput  shown  in  Tables  D-l  through  0-4-  This  is  the  NADIN  IA  base  traffic  to 
which  the  various  RMMS  increments  are  added  in  Pfcane  I  and  Phase  II. 

D.3  PHASE  I  RMMS  PLUS  NADIN  IA  TRAFFIC 


Phase  1  RMMS  traffic  (Table  C-3)  betwe*  Enroute  MPSs  will  be  carried  by  NADIN. 
The  sum  of  this  traffic  plus  the  NADI**  I A  baae  traffic  is  shown  in  Table  D-5.  The  RMMS 
gross  throughput  is  based  or  the  link  and  message  overheads  for  the  Alternative  1 
Architecture  described  in  Section  3 .  The  model  in  Section  D.l  applies  under  this 
assumption. 


MESSAGE  CHARACTERISTICS 


PEAK  THROUGHPUT  (B/S) 


MSG  TYPE  ACCOUNT  MSG/HR  MEAN  CHAR  NET  GROSS 

IN  24  50  8  8 
II  N  4,890  120  1,304  2,344 
II  Y  1,101  120  296  528 
III  N  14  3,000  96  112 


V  N  6  90,000  1,232  1,448 

V  N  459  15  16  104 


TABLE  D-1:  NADIN  IA  SWITCH  TO  CONCENTRATOR  PEAK  PERIOD  TRAFFIC 

(WITHOUT  RMMS) 


MESSAGE 

CHARACTERISTICS 

MSG  TYPE 

ACCOUNT 

MSG/HR 

MEAN  CHAR 

I 

N 

840 

50 

II 

Y 

1,120 

120 

II 

N 

90 

120 

V 

N 

459 

15 

PEAK  THROUGHPUT  (B/S) 


GROSS 


TOTALS 


2,509 


TABLE  D-2:  NADIN  IA  CONCENTRATOR  TO  SWITCH  PEAK  PERIOD  TRAFFIC 


(WITHOUT  RMMS) 


MESSAGE  CHARACTERISTICS 


PEAK  THROUGHPUT  (B/S) 


MSG  TYPE 

ACCOUNT 

MSG/HR 

MEAN  CHAR 

NET 

GROSS 

II 

N 

324 

120 

88 

II 

Y 

2,355 

120 

632 

hi 

N 

90 

616 

IV 

N 

6 

■ 

1,104 

1,448 

TOTALS 

2,775 

2,440 

3,464 

» 


LINK 

PEAK  THROUGHPUT 

FROM 

TO 

MSG/HR 

NET  BIT/SEC 

GROSS  BIT/SEC 

Switch 

Concentrator 

7,694 

3,056 

4,872 

Concentrator 

Switch 

3,709 

544 

1,272 

ATL  Switch 

SLC  Switch 

3,975 

2,544 

3,792 

SLC  Switch 

ATL  Switch 

6,740 

1,344 

2,728 

E  MPS 

Concentrator 

1,200 

104 

328 

Concentr.  or 

E  MPS 

1,200 

104 

328 

D.4  PHASE  II  RMMS  TRAFFIC 


The  general  NAS  Sector  Maintenance  Processor  Subsystems  will  communicate  with  the 
Enroute  MPS,  remote  facilities  and  work  centers  via  the  NADIN  concentrator.  Virtually  all 
general  NAS  Sector  MPS  traffic  will  be  local,  i.e.,  originating  and  ending  in  the  same 
enroute  area.  NADIN  I A  will  provide  local  switching  at  the  concentrator.  Hence  there  will 
be  no  increased  traffic  load  on  the  NADIN  backbone  due  to  the  Sector  MPSs  in  and  of 
themselves.  However,  the  NADIN  concentrator  will  be  required  to  process  this  local  traffic. 

The  volume  of  general  NAS  Sector  traffic  depends  on  the  number  of  remotely 
monitored  facilities.  Two  scenarios  are  quantified.  First,  if  there  are  no  RMS  facilities 
beyond  Phase  I  (RCAG  and  VORTAC)  then  the  traffic  for  the  various  RMMS/NADIN  and 
NADIN  backbone  links  is  as  shown  in  Table  D-6.  This  level  is  called  Phase  II,  Scenario  I. 
Second,  if  the  full  range  of  RMS  facilities  described  in  Section  2.3.3  are  implemented  then 
the  general  NAS  Sector  MPSs  will  result  in  the  total  gross  traffic  shown  in  Table  D-7.  This 
is  designated  Phase  n,  Scenario  n.  These  values  are  based  on  the  following  principles: 

•  General  NAS  Sector  MPSs  will  receive  (from  the  Enroute  MPS)  Certification 
Reports,  Alarm  Messages,  Alarm  Ends,  Status  Requests,  Free  Format  Messages 
and  Administrative  Messages  (Appendix  C), 

•  General  NAS  Sector  MPSs  will  send  Certification  Histories,  Status  Reports,  Free 
Format  Messages  and  Administrative  Messages, 

•  The  number  of  remotely  monitored  facilities  for  a  busy  general  NAS  Sector  is 
assumed  to  be  twice  the  average, 

D.5  MODIFIED  RMMS  CONFIGURATION 


The  scenarios  described  in  this  report  are  undergoing  revisions  at  this  time.  Recent 
modifications  to  the  RMMS  program  call  for  homing  VORTAC  RMC-Fs  to  the  General  NAS 
Sector  Maintenance  Processor  Subsystem  (GNS  MPS)  rather  than  to  the  Enroute  MPS.  In 
some  cases  the  RMC-C  would  serve  as  a  buffer  to  the  GNS  MPS  while  in  others  the  RMC-Fs 
would  be  connected  via  multidrop  lines  directly  to  the  Sector  MPS.  In  addition  work  center 
fixed  terminals  would  be  connected  to  their  Sector  MPS  rather  than  the  Enroute  MPS.  It  is 
also  proposed  under  the  new  scenario  that  the  Enroute  MPS  will  serve  as  the  site  of  the 
enroute  area  Maintenance  Management  System  (MMS)  data  base. 
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LINK 


GROSS  BITS/SEC 


FROM 

TO 

Sector  MPS 

NADIN  Concentrator 

63 

NADIN  Concentrator 

Sector  MPS 

186 

Enroute  MPS 

NADIN  Concentrator 

1,573 

NADIN  Concentrator 

Enroute  MPS 

739 

NADIN  Switch 

NADIN  Concentrator 

4,544 

NADIN  Concentrator 

NADIN  Switch 

944 

NADIN  Switch 

NADIN  Switch 

3,464 

TABLE  D-6: _ GROSS  LINK  THROUGHPUT  IN  PHASE  II,  SCENARIO  I 


LINK 

FROM 

TO 

Sector  MPS 

NADIN  Concentrator 

NADIN  Concentrator 

Sector  MPS 

Enroute  MPS 

NADIN  Concentrator 

NADIN  Concentrator 

Enroute  MPS 

NADIN  Switch 

NADIN  Concentrator 

NADIN  Concentrator 

NADIN  Switch 

NADIN  Switch 

NADIN  Switch 

GROSS  BITS/SEC 


40 

1,20 

10,00 

4,74 

6,70 

3,101 

5,631 


TABLE  D-7:  GROSS  LINK  THROUGHPUT  IN  PHASE  II,  SCENARIO  II 


The  effect  on  NADIN  backbone  traffic  load  appears  to  be  a  reduction  or  at  most  no 
change  from  that  based  on  the  original  program  plan.  On  the  one  hand  shifting  VORTAC  and 
work  centers  to  Sector  MPSs  should  reduce  the  NADIN  traffic  due  to  sectors  which  overlap 
two  or  more  enroute  areas.  On  the  other  hand,  copies  of  certification  reports  and  alarm 
messages  for  VORTAC  facilities  in  the  overlapping  sectors  will  be  sent  via  NADIN  from  the 
responsible  Sector  MPS  to  the  Enroute  MPS  in  the  adjacent  area.  Since  no  major  impact  to 
NADIN  throughput/delay  seems  likely  from  these  recent  proposed  changes  in  RMMS 
configuration,  the  original  quantitative  performance  results  are  not  recomputed  for  this 
altered  scenario. 
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APPENDIX  E 


RMMS  PERFORMANCE  REQUIREMENTS 


Service  requirements  which  must  be  satisfied  for  RMMS  data  communications  are 
discussed  in  this  appendix.  These  include  performance  thresholds  in  some  cases  and  in  other 
cases  include  service  features. 

E.l  PRIORITIES 


Alarm  and  status  change  messages  have  the  highest  priority  in  the  RMMS  system.  This 
priority  is  recognized  by  the  RMS  and  MPS  which  give  non-preemptive  preference  to  alarms 
over  certification  and  other  reports.  Once  in  NADIN  however,  all  RMMS  messages  will  have 
priority  indicator  JJ  and  be  given  NADIN  priority  four. 

E.2  TRANSMISSION  DELAYS 

NADIN  must  deliver  alarm  notification-  in  a  timely  manner  to  adjacent  MPSs. 
Delays  T  described  below  consist  of  three  components: 

TE  =  time  to  enter  NADIN  from  MPS  I/O  processor 

T^  =  NADIN  end  to  end  delay 

Tx  =  time  to  exit  f  NADIN  to  MPS  I/O 

The  total  delay  T  is  given  by: 

T  =  TEtTN  +  TX' 

For  alarm  and  other  time  critical  messages,  the  average  value  of  delay  T  shall  be  no  greater 
than  3  seconds  with  the  value  of  T  less  than  5  seconds  90  percent  of  the  time.  The  alarms 


transiting  NADIN  will  almost  exclusively  be  notification  to  secondarily  responsible  personnel 
such  as  Sector  Offices.  Primary  notification  is  almost  always  sent  within  the  originating 
enroute  area.  Certification  reports  and  other  non-time  critical  messages  will  be  required  to 
have  an  average  delay  T  of  5  seconds  with  T  less  than  7  seconds  90  percent  of  the  time. 

E.3  AVAILABILITY/RELIABILITY 


The  MPS  itself  has  been  specified  (Reference  7)  to  be  highly  reliable.  The 
MPS/NADIN/MPS  connection  shall  be  at  least  as  reliable  and  available  as  the  MPS  itself. 
This  requires  specifically  that  at  minimum: 

•  Availability  of  NADIN  Connection  ^  .9996 

•  Mean  Time  Between  Failure  (MTBF)  —  5000  hours 


•  Mean  Time  to  Repair  ^  30  minutes 

•  Periodic  Preventive  Maintenance  ^  30  minutes  per  720  hours 


E.4  ACCESSIBILITY 


The  RMMS  recognizes  four  levels  of  user  authorization  (Reference  7).  NADIN  or  any 
other  communications  utility  used  by  the  RMMS  is  required  to  deliver  the  user’s  authoriza¬ 
tion  code  to  the  destination  MPS.  However,  the  MPS,  not  NADIN,  is  responsible  for 
interpreting  the  authorization  code  and  ensuring  that  user  access  is  limited  to  the 
appropriate  level. 

E.5  RETRIEV  ABILITY 


MPS  to  MPS  traffic  in  Phase  I  implementation  will  not  require  NADIN  retrievability 
since  this  traffic  is  generally  recoverable  from  the  source  MPS  itself. 


R.6  PHASE  II  AND  BEYOND 


Several  functional  requirements  can  be  identified  for  Phase  n  and  subsequent  RMMS 
implementation.  These  ares 

•  File  transfers  -  between  Sector,  Enroute,  Regional  and  National  MPSs, 

•  Local  traffic  -  NAS  Sector  MPS  traffic  which  requires  only  local  switching 
(inside  enroute  area), 

•  Terminal  access  direct  to  NADIN  -  locations  such  as  National  Headquarters, 
Academy  and  others. 

•  Interactive  Freeformat  Terminal  Communications 

Quantification  of  these  requirements  will  not  be  possible  until  the  Maintenance 
Management  System  and  related  planning  has  progressed  further.  However,  Phase  n 
terminal  access  has  been  decided.  Specifically  terminals  shall  be  permitted  access  to  a 
remote  site  only  if  it  supplies  to  its  Enroute  MPS  the  complete  address  of  the  remote  site 
including  the  remote  site's  Enroute  MPS  address.  NADIN  will  then  be  required  to  deliver  the 
message  to  the  appropriate  NADIN  concentrator  for  hand  off  to  the  remote  MPS. 

Terminals  seeking  reports  on  a  remote  site  will  communicate  with  their  (terminals') 
Enroute  MPS  which  will  retrieve  the  data  from  the  appropriate  Sector,  Regional  or  National 
MPS  via  NADIN. 
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APPENDIX  F 

DELAYS 


Delays  encountered  by  messages  on  NADIN  and  the  RMMS/NADIN  interfaces  fall  into 
three  major  categories: 

•  queueing  delays  for  each  link  used, 

•  transmission  time  on  each  link,  and 

•  node  processing  delays. 

The  total  N  ADIN  delay  (TD)  would  thus  be  calculated  as: 


TD  = 

L 

V*‘ 

3TQ.  = 

the 

-3 

JS 

ii 

the 

TN  = 

the 

n  = 

the 

r 


TN 


the  queueing  delay  on  link  i,  in  seconds, 
the  message  transmission  time  on  link  i,  in  seconds, 
the  processing  time  per  node,  in  seconds,  and 
the  number  of  NADIN  backbone  links  involved  in  the  transmission. 
The  processing  delay  per  node  is  conservatively  estimated  to  be  50  milliseconds,  i.e.: 


TN 


.05  seconds 


The  transmission  time  is  determined  from; 


TMj  =  GL  x  B/C. 


where  CL  is  the  transmission  rate  (capacity)  on  link  i,  in  bits  per  second, 


and  GL  and  B  are  the  gross  message  length  and  bits  per  character  as  discussed  earlier. 

For  the  links  between  a  switch  and  concentrator,  C.  =  9,600  b/s.  On  the  switch-to-switch 
link,  although  the  effective  capacity  is  19,200  b/s,  a  given  message  will  always  be 
transmitted  over  a  single  9,600  b/s  channel.  Hence,  C.  =  9,600  b/s  for  the  dual-channel  link 
also.  Thus,  for  a  NADIN  message,  consisting  of  one  full  frame  of  256  characters  including 
headers  and  trailers: 

T!VL  =  256  x  1.016  x  8/9,600  =  .22  seconds,  for  a  9600  b/s  link. 


Using  the  above  results,  the  network  delay  can  be  expressed  as: 

n 

TD  =  (nx.22)  +  (n  +  l)x.05+X)  TQ. 

i=l  1 


n 

.86  +  52  TQ.,  if  n  =  3 
i=l  1 


Determination  of  the  queueing  delays  requires  the  consideration  of  several  variations. 
Primary  among  these  is  the  presence  or  absence  of  files  to  be  transferred.  Another 
important  variation  is  the  use  of  single  or  dual  transmission  channels.  The  procedures  used 
to  estimate  the  queueing  delays  are  based  on  the  analyses  detailed  in  Reference  13. 

Delays  are  also  calculated  for  RMMS  messages  including  processing  time  at  an  enroute 
Maintenance  Processor  System,  transit  through  NADIN  to  the  destination  MPS  and 
processing  there.  The  total  RMMS  delay  (TR)  is  calculated: 


TR  =  TD  +  2TN  +  TE  +  TX 

where 

TD  =  total  network  delay  as  above,  in  seconds, 

TN  =  processing  time  per  MPS  node,  in  seconds, 

TE  =  entry  delay  from  Enroute  MPS  to  NADIN  concentrator  in  seconds, 

and 

TX  =  exit  delay  from  NADIN  concentrator  to  Enroute  MPS. 

The  value  of  TN  is  again  estimated  at  50  milliseconds,  i.e.: 

TN  =  .05  seconds 

For  different  scenarios  the  Enroute  MPS/NADIN  interface  speed  changes.  Delays  for 
various  link  capacities  are  computed. 

F.l  QUEUEING  DELAYS  IN  THE  ABSENCE  OF  PILE  TRANSFERS 

On  links  involving  no  file  transfers,  messages  can  be  assumed  to  arrive  at  random.  For 
the  single-channel  links  including  the  MPS/concentrator  links,  the  queueing  delay  will  be 
approximately: 

TQj  =  TF.  x  Uj/d-U.) 

where  TF.  =  the  average  transmission  time,  in  seconds,  per  frame  on  link  i, 

=  GLF  x  B/Cj 

GLF  =  the  gross  length,  in  characters,  of  an  average  frame, 

and  U.,  C.  and  B  are  the  link  utilization,  link  capacity  and  bits  per  character 
respectively. 
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As  a  conservative  estimate,  a  full  frame  (245  characters)  is  considered  in  estimating 
TF..  Thus: 


GLF 

2£ 

(245  +  11)  x  1.016  =  260  characters 

TF. 

l 

= 

260  x  8/9,600  =  .22  seconds 

U. 

l 

= 

CGT./9,600 

u./(l- 

-Uj) 

= 

CGTj/O.eOO-CGTj) 

TQj 

= 

.22  x  CGT./(9,600-CGT.)  seconds,  for  the  single-channel  links, 

where 

CGT. 

l 

= 

cumulative  gross  throughput  on  link  i. 

The  above  approximation  assumes  random  (Poisson)  message  arrivals  and  a  standard 
deviation  of  frame  length  that  is  equal  to  the  average  frame  length  (a  conservative 

assumption),  The  bases  for  this  approximation  can  be  found  in  most  queueing  theory  texts 
(see,  for  example,  Reference  14,  Chapter  3). 

Files  will  be  transferred  in  both  directions  on  the  dual-channel  switch-to-switch  link. 
Peak-period  queueing  delays  for  those  links  would  thus  be  determined  as  discussed  below. 

F.2  QUEUEING  DELAYS  IN  THE  PRESENCE  OF  FILE  TRANSFERS 

The  relatively  large  file  (or  report)  transfers  introduced  by  FSAS  and  AFC  traffic  can 
create  intervals  of  several  minutes  during  which  a  link  will  be  transmitting  at  essentially 
full  capacity.  The  assumption  of  random  message  arrival,  used  above,  is  therefore  not 
applicable  during  such  intervals.  These  intervals  will  be  the  real  peak  periods  for  NADIN. 

As  recommended  in  the  Level  IA  Study  (Reference  13)  and  Reference  15,  it  is  assumed 
that  a  discipline  will  be  implemented  at  the  NADIN  switches,  such  that  large  file  transfers 
will  not  unduly  delay  other  message  traffic.  This  has  been  modeled  as  follows: 
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•  Consider  the  NADIN  backbone  link  connecting  a  switch  (Node  A)  and  an 
associated  concentrator  or  the  other  switch  (Node  B).  For  this  link,  Node  A  will 
effectively  maintain  a  number  of  output  message  queues,  one  for  each  output 
port  at  Node  B  (plus  a  top  priority  message  queue,  which  need  not  be  considered 
here). 

•  The  discipline  at  Node  A  will  cycle  through  the  queues  for  Node  B,  processing 
each  queue  in  turn. 

•  If  a  queue  (Queue  I)  is  empty,  it  is  instantly  passed  over. 

•  If  Queue  I  is  not  empty,  one  frame  from  that  queue  is  transmitted  to  Node  B  and 
processing  passes  to  Queue  I  +  1.  Any  other  message  frames  in  Queue  I  must 
await  processing  in  subsequent  cycles. 

The  mean  queueing  delay  for  the  first  or  only  frame  in  a  randomly  arriving  message, 
under  such  a  process  can  be  determined  approximately  (see  Reference  15)  as: 

TQ.  =  .75  x  TCj 

where 


TCj  =  mean  time  per  cycle  through  the  queues  for  link  i. 

TC.  is  determined  by  noting  that  during  the  file  transfer  interval  the  full  capacity  of 

‘  t 

the  link  is  utilized  (Uj  =  1.0)  and  a  relatively  fixed  amount  of  time  (TFj )  is  devoted  in  each 
cycle  to  the  transfer  of  the  file  frame(s). 

If  U  j  is  the  utilization  associated  with  the  random  (non-file  transfer)  traffic, 

then 


TFj/TCj  =  1-U. 

i.e.,  the  fraction  of  the  cycle  time  devoted  to  file  transfer  is  equal  to  the  fraction  of  the 
capacity  not  used  for  random  traffic. 
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Thus: 


TCj  =  TFj  /(I  -  Ul ) 
u!  =  (CGT.  -  GFT.)/C. 

where  GFT.  =  gross  throughput  requirement  for  file  transfers  on  link  i 

(averaged  over  the  peak  hour) 

and  CGT.  and  C.  are  the  gross  throughput  and  capacity  for  link  i,  as  discussed  earlier. 
Combining  the  above  expressions: 

TQj  =  .75  x  TF!  x  C./(Cj  +  GFT.  -  CGTj) 

For  the  message  traffic  considered  in  this  study,  two  "file  transfer"  queues  would 
exist,  one  for  the  scheduled  FSAS  files  and  the  other  for  the  long  (30,000  character)  AFC 
reports.  Table  F-l  summarizes  the  throughput  on  each  NADIN  link  associated  with  such 
transfers.  The  values  shown  in  that  table  are  the  values  for  GFTj  and  for  U.',  the  random 
message  utilization. 

Since  GFTf  =  0  for  concentrator-to-s  witch  links  and  MPS/NADIN  links,  queueing  delay 
for  those  links  would  be  determined  as  described  in  F.l  above. 

For  the  switch-to-concentrator  links,  both  file  transfer  queues  may  contain  frames 
simultaneously.  Thus: 

TF.  =  2  x  TF.  =  .44  seconds 

l  i 

where  TF.  =  the  full  frame  transmission  time  (.22  seconds),  discussed 

earlier. 

and  TQj  =  .75  x  .44  x  9,600/(9,600  +  GFTj  -  CGT.) 

=  3,168/(9,600  +  GFTj  -  CGTj)  seconds. 

t 

Determining  TF.  for  the  switch-to-switch  links  is  not  as  direct.  Since  there  are  two 
9,600  b/s  channels,  a  randomly  arriving  message  can  be  transmitted  over  the  second  channel 
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while  a  file  frame  is  being  transmitted  on  the  first.  It  is  convenient  therefore  to  treat  this 
case  as  if  there  were  a  single  19,200  b/s  channel;  i.e.: 

Ci  *  19,200 

TF.  =  m  x  260  x  8/19,200  =  m  x  .11 

where  m  =  the  number  of  file  queues  used. 

Note  however  that  the  value  of  TF.  is  based  on  the  speed  of  a  single  channel,  i.e,  9600  b/s. 
Thus,  for  the  Atlanta  to  Salt  Lake  City  link: 

TQ.  =  .75  x  .22  x  19,200/(19,200  +  GFTj  -  CGTj) 

=  3168/(19,200  +  GFT.  -  CGTj)  seconds. 

For  the  Salt  Lake  City  to  Atlanta  link: 

TQj  =  .75  x  .11  x  19,200/(19,200  +  GFTj  -  CGT.) 

=  1584/(19,200  +  GFTj  -  CGT.)  seconds 

F.3  DELAY  SUMMARY 


The  above  expressions  have  been  used  to  determine  the  average  queueing  delays  for 
each  NADIN  backbone  link  and  the  Enroute  MPS/NADIN  concentrator  links  under  various 
loading  environments.  The  results  of  these  calculations  are  shown  in  Tables  F-2  and  F-3 
respectively. 

The  queueing  delays  shown  in  Tables  F-2  and  F-3  are  used  to  calculate  NADIN  and 
RMMS  delays  as  discussed  earlier.  Thus,  for  example,  an  RMMS  message  transmitted  from 
an  Enroute  MPS  in  Memphis  to  an  Enroute  MPS  in  Fort  Worth  will  encounter  the  following 
delays  in  Phase  I: 
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ENVIRONMENT 

FILE  TRANSFER 

LINK  QUEUEING  DELAYS  (SECONDS) 

NC  TO  NS 

NS  TO  NS 

NS  TO  NC 

NADIN  IA 

Y 

.03 

.19 

.49 

N 

.03 

.03 

.11 

Phase  I 

Y 

.04 

.20 

.52 

N 

.04 

.04 

.13 

Phase  II,  Scenario  I 

Y 

.04 

.20 

.52 

N 

.04 

.04 

.13 

NC  =  NADIN  Concentrator 
NS  =  NADIN  Switch 


TABLE  F-2:  NADIN  BACKBONE  QUEUEING  DELAYS  TQ. 
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ENVIRONMENT 


E  MRS  TO  NC  (SEC) 


NC  TO  E  MPS  (SEC) 


2400  B/S  4800  B/S  2400  B/S  4800  B/S 

Phase  I  .06  -  .06 

Phase  II,  Scenario  I  .77  .1  .18  .04 

E  MPS  =  Enroute  MPS 

NC  =  NADIN  Concentrator 
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•  Node  Processing  Delays  (6  nodes)  =  6  x  .05  s  .30 

•  Transmission  Delays  (3  NADIN  links  +  2  access  links)  =  1.46 


Queueing  Delays  (5  links): 

E  MPS  to  NC  = 

.06 

NC  to  NS 

.04 

NS  to  NS 

.20 

NS  to  NC 

.52 

NC  to  E  MPS 

.06 

Total  Delay  = 

2.64 

Table  4-2  shows  the  total  end-to-end  delays  in  NADIN  from  concentrator  to  switch  to 
switch  to  concentrator.  Delays  are  shown  for  the  average  RMMS  message  (average  gross 
length  =  120  characters)  and  for  a  single  full  frame  message  (gross  length  =  256  characters). 
Table  4-3  shows  the  total  end-to-end  average  delay  for  an  RMMS  message  from  an  Enroute 
MPS,  through  NADIN  as  described  above,  to  a  remote  Enroute  MPS. 
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APPENDIX  G 


HOST-TO-HOST  PROTOCOL  ISSUES  IN  THE  RMMS  AND  MMS 


The  RMMS  and  MMS  each  consist  of  a  number  of  processes  running  on  geographically 
dispersed  hosts  (MPSs)  communicating  via  an  intervening  network  (NADIN).  The  role  of  the 
lower  three  protocol  layers  (physical,  link  and  network)  in  the  ISO  model  is  to  guarantee 
delivery  of  data  from  Data  Terminal  Equipment  (DTE)  to  Data  Terminal  Equipment,  i.  e., 
computer  (or  front-end)  to  computer.  But  this  is  not  sufficient.  A  higher  layer,  the 
transport  layer  (References  6  and  12),  has  the  job  of  providing  a  reliable  and  efficient  end- 
to-end  delivery  of  data  between  MPS  processes  rather  than  just  between  machines.  To 
ensure  that  exchanged  data  can  be  understood  and  acted  on  effectively  is  the  role  of  the 
higher  layers,  particularly  Layer  6,  the  presentation  layer,  and  of  course  finally  Layer  7,  the 
application  layer. 

In  the  subsequent  sections,  Layer  4,  the  protocol  layer,  is  discussed  in  more  depth.  In 
addition,  several  issues  in  the  presentation  layer  are  identified  for  future  consideration  in 
RMMS  and  MMS  program  implementation. 

G.l  THE  TRANSPORT  LAYER  IN  GENERAL 


The  transport  layer  described  here  is  the  means  by  which  MPS  processes  establish  and 
terminate  connections  with  each  other,  handle  buffering  and  flow  control,  recover  from 
errors  and  perform  other  related  functions.  This  layer  defines  a  set  of  transport  addresses 
or  sockets  through  which  interprocess  communications  occur.  For  example,  transport 
addresses  in  NADIN  would  be  specified  by  NADIN  node  (concentrator),  physical  port  and 
socket  (or  logical  port)  number.  On  a  given  MPS  each  process  will  correspond  to  a  unique 
socket  number.  A  well  designed  transport  layer  will  enable  processes  to  communicate  in  an 
error  free  manner  without  regard  to  the  characteristics  of  the  underlying  communications 
medium  or  subnetwork. 

The  basic  primitives  in  nearly  all  transport  protocols  include  at  a  minimum  CONNECT, 
LISTEN,  CLOSE,  SEND,  and  RECEIVE.  A  CONNECT  request  announces  that  a  process 
wishes  to  establish  a  connection  or  association  with  another  named  process.  A  LISTEN 
request  indicates  a  process'  willingness  to  accept  connections.  A  CLOSE  request  terminates 


connections.  A  RECEIVE  primitive  indicates  that  a  process  is  willing  to  receive  and  has 
allocated  buffers.  A  SEND  call  transmits  the  contents  of  a  buffer  on  the  indicated  transport 
connection.  More  detailed  discussions  of  the  use  and  implementation  of  transport  protocols 
is  to  be  found  in  References  6  and  12. 

G‘2  PRESENTATION  LAYER  ISSUES  (LAYER  6) 

This  layer  provides  additional  services  to  facilitate  the  useful  exchange  of  information 
between  processes.  For  MPS-to-MPS  communication,  the  most  important  of  these  is  file 
transfer  service,  although  there  may  someday  be  need  for  cryptographic  transformation. 
Text  compression  is  another  service  of  Layer  6  which  could  be  useful  to  RMMS/MMS.  The 
function  of  text  compression  is  to  reduce  the  number  of  bits  which  must  be  sent  through  the 
communications  medium.  Since  bandwidth  is  becoming  more  expensive  while  computing 
power  is  becoming  less  expensive,  this  is  a  possible  cost  cutting  strategy  for  any  distributed 
system. 

G.2.1  File  Transfer  Protocol 


Files  can  be  transferred  from  machine  to  machine  in  a  homogeneous  environment 
without  much  concern.  However,  in  a  heterogeneous  environment  this  task  is  much  more 
difficult.  It  is  the  function  of  the  file  transfer  protocol  to  achieve  this  transfe*-  smoothly 
between  incompatible  machines.  Appropriate  conversions  must  be  performed  by  the  file 
transfer  protocol.  Initially  the  MPSs  will  all  be  Tandem  T16s  talking  only  to  each  other. 
Whether  or  not  the  general  NAS  Sector  MPSs  will  also  be  Tandem  is  not  yet  determined. 
However,  even  if  they  are,  it  is  likely  that  at  some  point  in  the  future  interconnections 
between  the  MPSs  and  other  host  computers  such  as  the  9020R  will  be  desired.  Early 
planning  and  development  of  a  file  transfer  protocol  (perhaps  provided  by  NADIN  in  the 
future)  would  facilitate  this  interconnectivity. 
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APPENDIX  H 


NADIN  AND  RMMS/MMS  INTERFACE  CONTROL  DOCUMENT 


H.l  INTRODUCTION 


H.l.l  Purpose 

This  appendix  describes  the  interface  requirements  which  must  be  incorporated  in  the 
NADIN  and  RMMS/MMS  designs  in  order  to  exchange  RMMS/MMS  data  traffic  through 
NADIN.  It  is  anticipated  that  each  MPS  will  interface  with  a  NADIN  concentrator.  The 
hardware  and  procedural  characteristics  described  herein  shall  be  provided  at  each  interface 
with  NADIN. 

H.l. 2  Organization 

This  appendix  provides  a  brief  overview  of  the  interface  characteristics,  followed  by 
specific  physical,  link  and  transport  levels  of  interface  requirements  that  shall  be 
incorporated  in  the  NADIN  and  RMMS/MMS  implementations. 

H.l.3  Assumptions 

In  the  event  of  NADIN  Switching  Center  failure  it  is  assumed  the  entire  RMMS 
requirement  will  be  supported  through  the  surviving  NADIN  switching  center.  (NADIN 
Concentrators  wiU  rehome  on  the  surviving  switch  automatically). 

H.l.4  Technical  Summary 

This  interface  shall  support  data  exchanges  of  2400  b/s,  over  bit  serial  synchronous 
channels.  The  channel  shall  be  implemented  in  a  full  duplex  DTE-to-DTE  configuration  per 
EIA  RS-449  (balanced)  standards  (Figure  H-l).  Link  control  shall  be  in  accordance  with 
FED-STD-I003  (ANSI  X3.66-1979,  Advanced  Data  Cor municatior  Control  Procedure, 
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RS-422  ORIVERS  AND  RECEIVERS  WILL  BE  USED 


RS-449 

CCITT  V.24 

SG 

102 

RD-A' 

RD-B’ 

104 

RR-A* 

109 

RR-B' 

SD-A 

SD-B 

103 

RS-A 

RS-B 

105 

ST-A1 

114 

ST-B ' 

RT-A* 

RT-B ' 

115 

DESCRIPTION 

SIGNAL  GROUND 
RECEIVED  DATA 

DATA  CHANNEL  RECEIVED  LINE 
SIGNAL  DETECTOR 

TRANSMITTED  DATA 

REQUEST  TO  SEND 

TRANSMITTER  SIGNAL  ELEMENT 
TIMING 

RECEIVER  SIGNAL  ELEMENT  TIMING 


•  THE  MPS  SHALL  PROVIDE  THE  DATA  SIGNAL  TRANSPOSITION  FOR  CCITT  CIRCUITS 
104  TO  103  AND  CIRCUITS  105  TO  109. 

•  A  37  PIN  RS-449  DTE  CONNECTOR  SHALL  BE  SUPPLIED  ON  NADIN 

•  BECAUSE  RS-422  DRIVERS  AND  RECEIVERS  ARE  8EING  USED  THIS  INTERFACE  WILL 
NOT  BE  COMPATIBLE  WITH  RS-232 

•  CLOCKS  FROM  MPS 


FIGURE  H-l:  MPS  TO  NADIN  RS-449  DIRECT  INTERFACE 
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ADCCP)  with  options  1,  2,  7  and  11  implemented.  The  normal  operating  mode  shall  he 
balanced  asynchronous  (BA).  The  NAD1N  and  WPS  elements  shall  operate  as  combined 
stations.  Data  shall  be  exchanged  on  a  frame  basis.  Frame  format  is  not  specified  in  this 
ICD.  Data  may  be  in  any  code  or  as  a  stream  of  bits. 

H.2  PHYSICAL  INTERFACE 


H.2.1  Electrical  and  Mechanical  Interface 


Tiie  mechanical  interface  between  the  NAD1N-MPS  shall  be  in  accordance  with  EIA 
Standard  RS-449  with  the  electrical  interface  conforming  to  RS-422  balanced  voltage. 

H.2, 2  Communications  Facility 

The  communication  facilities  for  the  NADIN-MPS  interfaces  can  be  one  of  two  types: 
local  where  the  NADIN  node  is  located  within  the  distance  limits  of  the 
electrical/mechanical  interface  (about  1000  meters)  and  remote  where  the  NADIN  node  is 
located  beyond  the  limited  distance.  In  either  case  the  interface  shall  be  a  synchronous 
communication  full-duplex  channel. 

H.2. 2.1  Local  Facility 

For  NADIN  nodes  locally  located  from  the  Enroute  MPS,  the  communication  facilities 
shall  be  twisted  pair  cables.  Limited  distance  modems  may  be  used.  The  cable  shall  be 
supplied  by  the  RMMS  program.  When  interconnecting  by  cable  without  modem,  the  clock 
signal  shall  be  provided  by  the  MPS;  data  signals  (RD  and  SD)  and  timing  signals  (RT  and  ST) 
shall  be  transposed  by  the  cable. 

H.2. 2. 2  Remote  Facility 

For  NADIN  nodes  remotely  located  from  the  Sector  MPS,  the  communication  facilities 
shall  be  4-wire  circuit  of  conditioned  type  3002  and  modems  in  accordance  with  FED-STD- 
1005  or  FED-STD-100S.  The  modems  shall  be  capable  of  handling  full  duplex,  synchronous 
transmissions  at  2400  or  4800  b/s.  Spare  modems  shall  be  available  in  the  event  of  modem 
failure. 
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H.3  LINK  CONTROL  PROCEDURE 


The  procedure  utilized  on  this  interface  shall  be  in  accordance  with  the  procedures 
presented  in  FED-STD-1003  and  expanded  herein.  This  is  a  two-way  simultaneous  non- 
switched,  point-to-point  protocol  employing  code  and  byte  independent  transmission.  The 
Balanced  Asynchronous  (BA)  Mode  shall  be  used,  without  extension  of  the  Control  Field. 
Tiie  RSET,  SREJ,  UI,  UP,  RIM  and  SIM  commands  and  responses  shall  not  be  used. 

H.3.1  Class  of  Operation:  Balanced  Asynchronous 

Under  the  Balanced  Asynchronous  procedure,  each  of  the  two  stations  on  a  point  -to- 
point  link  is  a  combined  (primary  and  secondary)  station.  As  appropriate,  either  of  the  two 
stations  can  take  on  the  primary  role  (send  commands),  causing  the  other  to  take  on  the 
secondary  role  (send  responses). 

TI.3.2  Frame  Structure 


The  unit  of  transmission  under  ADCCP  is  the  frame.  Each  frame  transmitted  from 
any  type  of  station  must  contain  an  opening  flag  sequence,  address  field,  control  field, 
information  fund,  frame  check  sequence,  and  ending  flag  sequence.  The  information  field 
need  not  be  included.  Messages  used  for  link  control  only,  however,  if  present,  must  not 
exceed  a  maximum  of  2000  bits.  The  Control  Field  extension  shall  not  be  used. 

H.3.3  Addressing 

ADCCP  requires  that  a  unique  address  be  associated  with  all  secondary  stations  on  a 
link  (this  includes  all  combined  stations).  Any  transmission  to  or  from  a  secondary  station 
shall  contain  the  address  of  that  station  in  the  address  field. 


H. 3.3.1  Address  Field 


The  ADCCP  address  field  shall  use  a  single  octet  where  the  least  significant  bit  of 
each  address  shall  be  l.  The  address  octet  shall  be  as  follows: 

SECONDARY 

STATION  bx  b2  b3  b4  bg  bg  b?  bg 

MPS  1  1  0  0  0  0  0  0 

NADIN  10000000 

CONCENTRATOR 

H.3.3.2  Global  and  Null  Address 

The  global  address,  eight  "1"  bits  shall  not  be  used  since  no  switched  lines  will  be  used 
in  the  NADIN  and  RMMS  interface.  The  null  address,  eight  "0”  bits,  shall  be  used  for  testing 
purposes  only  and  shall  be  ignored  by  the  secondary  station  function.  The  null  address  can 
be  used  in  situations  where  it  is  desired  to  exercise  a  station's  transmit  abilities  without 
requiring  station  action  or  reply. 

H.3.4  Link  Control  Functions 

ADCCP  provides  for  a  variety  of  control  functions.  These  are  defined  as  a  series  of 
basic  commands  and  responses  together  with  a  series  of  optional  commands  and  responses. 
The  ADCCP  Standard  in  FED-STD-1003  describes  these  functions  in  detail.  The  following 
outlines  those  that  shall  be  implemented  for  the  RMMS  and  NADIN  interface. 

H.3.4. 1  Basic  Functions 

The  basic  control  functions  include  both  commands  (i.e.,  from  primary  stations)  and 
response  (i.e.,  from  secondary  stations).  The  following  identifies  these  functions  as  they 
apply  to  RMMS  and  NADIN: 


FUNCTION  TYPE* 


MEANING 


I 

CicR 

RR 

C3cR 

RNR 

CdcR 

FRMR 

R 

SABM 

C 

DISC 

C 

UA 

R 

DM 

R 

Information  being  transferred. 
Receive  Ready 
Receive  Not  Ready 
Frame  Reject 

Set  Asynchronous  Balanced  Mode 
(BA  procedures  only) 

Disconnect 

Unnumbered  Acknowledgement 
Disconnected  Mode 


*C=  Command;  R  =  Response 


In  addition  there  is  a  basic  command  RSET  (Reset)  for  BA  procedures  which  shall  not  be 
used. 


H.3.4.2  Optional  Functions 

ADCCP  provides  eleven  options  for  adding  or  deleting  control  functions.  For  the 
RMMS  and  NADIN  interface,  options  1,  2,  7,  and  11  shall  be  implemented  and  are  described 
as  follows: 


ADD/ 


OPTION# 

DELETE* 

TYPE* 

FUNCTION 

MEANING 

1 

A 

C<5cR 

XID 

Exchange  Identification 

A 

R 

RD 

Recuest  Disconnect 

2 

A 

CdcR 

REJ 

Reject 

7 

A 

CicR 

— 

Multiple  Octet  Address 

11 

D 

C 

RSET 

(Delete  the  Basic  Reset 

Command) 


*A  =  Add  Function;  D  =  Delete  Function;  C  =  Command;  R  =  Response 
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H.3.5  Link  Control  Timers 


Often  an  expected  acknowledgement  or  response  is  not  received  due  to  transmission 
losses  or  FCS  errors  (for  messages  in  either  direction).  To  help  detect  such  conditions 
efficiently,  time-out  functions  shall  be  implemented.  Time-out  functions  shall  (l)  initialize 
a  timer  when  a  transmission  requiring  an  acknowledgement  or  response  is  sent,  (2)  stop  the 
timer  when  the  acknowledgement  or  response  is  received,  and  (3)  note  a  time-out  condition 
when  a  prespecified  time  has  elapsed  without  the  expected  acknowledgement  or  response 
having  been  received.  If  the  time-out  condition  occurs,  recovery  actions  shall  be  taken, 
generally  involving  retransmission  of  the  frame  that  started  the  process. 

H.3.5.1  Timer  Functions 

The  time-out  functions  specified  in  this  section  represent  the  minimum  requirements 
and  do  not  preclude  other  time-out  functions.  The  necessary  timers  and  their  functions  are: 

•  Poll  Timer  -  used  at  a  primary/combined  station  to  detect  the  lack  of  a 
response  to  a  poll.  Also  used  to  delimit  the  check  point  cycle  in  the  absence  of 
poll  response. 

•  Information  Ack  Timer  -  used  to  detect  missing  or  unacknowledged  information 
frames  that  will  not  show  up  as  an  out-of-sequence  exception.  This  timer  is 
important  if  and  when  a  single  or  final  information  frame  is  transmitted  which 
does  not  contain  a  P  bit  set  to  "1". 

•  Sent  REJ  Timer  -  used  to  detect  the  lack  of  receipt  of  response  to  an  REJ 
command/response.  Similar  timers  may  be  implemented  for  other 
command/responses  in  addition  to  REJ. 

•  Busy  (RNR)  Timer  -  used  by  a  secondary/combined  station  to  determine  when  it 
can  resume  sending  I  or  UI  frames  to  a  primary /combined  station  that  has  sent 
an  RNR  command  and  has  not  cleared  the  busy  condition  by  other  means. 


•  Idle  Timer  -  used  by  a  primary/combined  station  to  insure  that  a 
secondary /combined  station  is  polled  if  there  h  no  transmission  in  either 
direction  for  a  specified  time  duration. 

H.3.5.2  Timer  Values 


The  establishment  of  timer  values  shall  be  postponed  until  system  implementation. 
However,  at  a  minimum  timers  shall  be  adjustable  in  increments  of  .01  seconds  over  the 
range  0  to  300  seconds.  Recommended  initial  settings  are  shown  in  Table  H-l  in  terms  of 
recommended  upper  and  lower  limits  for  initial  timer  settings. 

H.3.5.3  Acknowledgement 

Each  time  a  station  receives  an  information  or  supervisory  frame,  it  expects 
acknowledgement  (through  the  N(R)  parameter)  of  information  frames  it  transmitted.  To 
facilitate  retransmission  of  unacknowledged  information  frames,  each  station  shall 
implement  checkpoint  recovery,  as  follows: 

•  A  checkpoint  cycle  is  defined  for  a  primary/combined  station  as  the  period 
between  the  transmission  of  a  frame  with  the  P  bit  set  to  1  and  either  (l)  the 
next  receipt  of  a  frame  with  the  F  bit  set  to  1  from  the  secondary  to  which  the 
poll  bit  was  directed,  or  (2)  the  expiration  of  the  poll  timer,  whichever  occurs 
first.  In  balanced  operation  a  combined  station  will  not  initiate  checkpoint 
retransmission  upon  the  receipt  of  a  frame  with  the  P  bit  set  to  1.  (A  cycle  does 
not  end  with  an  unnumbered  frame,  however.) 

•  At  the  end  of  each  cycle,  the  station  will  retransmit  any  unacknowledged  frames 
(per  the  value  of  N(R)  received)  that  had  been  transmitted  before  the  start  of 
the  cycle,  and  any  subsequent  frames  transmitted.  This  is  referred  to  as 
checkpoint  retransmission. 

•  If  an  REJ  frame  with  the  P/F  bit  set  to  0  is  received  during  such  a  cycle,  actions 
pertinent  to  the  REJ  condition,  rather  than  checkpoint  retransmission,  will  be 
implemented, 

•  See  ADCCP,  ANSI  X  3.66  -  1979  for  further  details  and  exceptions. 
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TIMER 

LOWER  LIMIT 

UPPER  LIMIT 

Poll 

1 

4 

I -Frame  response 

2 

4 

Sent  REJ 

1 

4 

Busy  (RNR) 

5 

120 

Idle 

1 

30 

a)  4800  bit/sec  link 

TIMER 

LOWER  LIMIT 

UPPER  LIMIT 

Poll 

.5 

2 

I-Frame  response 

1 

2 

Sent  REJ 

.5 

2 

Busy  (RNR) 

.5 

120 

Idle 

1 

30 

b)  9600  bit/sec  link 

TABLE  H-l;  TIMER  VALUES  -  SUGGESTED  INITIAL  LIMITS  (SECONDS) 


H. 3.5.4  Busy  Condition 


When  a  station  temporarily  cannot  receive  or  continue  to  receive  information  frames 
due  to  internal  constraints  (e.g.,  buffer  limitations),  it  should  notify  the  transmitting  station 
by  sending  an  RNR  Command /Response  and  report  its  condition  to  the  supervisor  function. 
Upon  receipt  of  an  RNR  frame,  a  station  shall  not  transmit  new  information  frames  to  the 
busy  station.  Clearance  of  the  busy  condition  shall  be  reported  by  transmission  of  an  RR, 
RE.T,  SABM,  or  UA  frame  with  or  without  the  P/F  bit  set  to  1;  or  transmission  of  an 
information  frame  with  the  P/F  bit  set  to  1.  If  the  busy  condition  has  not  been  cleared  by 
other  means,  the  expiration  of  the  busy  condition  timer  enables  a  secondary /combined 
station  to  resume  transmission  of  I  or  UI  frames  to  the  primary/combined  station.  e 
system  supervisor  function  shall  be  notified  when  the  busy  condition  is  cleared. 

II. 3. 6  Error  Control 


H.3.6.1  Frame  Check  Sequence 

The  frame  check  sequence  (FCS)  shall  be  a  16-bit  (2  octet)  number  generated  at  the 
transmitting  station  by  applying  a  special  algorithm  to  the  string  of  bits  that  make  up  the 
address  field,  the  control  field  and  (if  present)  the  information  field,  prior  to  zero  insertion. 
The  value  of  the  FCS  shall  be  determined  and  transmitted  as  part  of  each  frame. 

The  receiving  station,  after  removing  the  flag  sequences  and  the  inserted  zeros,  shall 
determine  if  the  received  FCS  is  consistent  with  the  remainder  of  the  transmission. 
Inconsistency  implies  an  error  in  transmission  and  shall  cause  the  transmission  to  be 
unacceptable. 

Appendix  D  to  ANSI  X3. 66-1979  defines  the  FCS  in  detail  and  suggests  techniques  *or 
implementing  this  process. 

H.3.6.2  Frame  Check  Sequence  Error 

Errors  introduced  during  the  transmission  of  a  frame  will  almost  always  cause  an  FCS 
error,  i.e.,  cause  the  received  value  of  the  FCS  to  differ  from  the  expected  value.  Frames 
with  such  an  error  shall  be  discarded. 


H.3.6.3  Frame  Reject  Condition 


When  a  frame  is  received  with  no  FCS  error,  but  contains  (1)  an  invalid  control  field, 
(2)  an  invalid  N(R)  or  (3)  an  information  field  with  more  than  2000  bits,  a  frame  reject 
condition  exists.  A  secondary  station,  upon  detecting  such  a  condition,  shall  notify  the 
primary  station  with  a  FRMR  response.  A  primary  station  upon  detecting  such  an  error  or 
upon  receiving  an  FkMR  response  shall  transmit  a  mode  setting  command  (SABM,  or  DISC). 
Higher  level  recovery  functions  may  also  be  implemented  by  the  primary  station. 

H.3.6.4  Frame  Sequence  Error 

Whenever  a  station  receives  an  otherwise  error-free  information  frame,  it  shall  check 
to  insure  that  the  value  of  N(S)  corresponds  to  the  receive  variable  R(A).  If  the  two  are  not 
identical,  a  frame  sequence  error  has  occurred.  At  the  earliest  opportunity  the  receiving 
station  shall  transmit  an  REJ  frame  to  the  original  transmitting  station,  with  N(R)  set  to 
R(A).  The  information  field(s)  from  the  erroneous  frame  and  any  subsequent  information 
frames  from  that  transmitting  station  shall  be  discarded,  until  one  with  N(S)  equal  to  R(A)  is 
received.  Other  control  information  (e.g.,  the  P/F  bit  and  N(R))  from  those  frames  will  be 
used.  The  original  .r^nsmit'iing  station,  upon  receiving  the  REJ  frame  shall  retransmit  the 
erroneous  frame  and  any  subsequent  information  frames  (in  order)  at  the  earliest 
opportunity. 

H.3.7  Recovery 

After  three  attempts  to  establish  communication  or  recover  an  errored  frame,  in 
either  direction,  the  primary  function  (of  the  combined  station)  shall  declare  the  link 
inoperable  and  produce  a  fault  report  to  the  link  supervisor  function. 

H.4  NETWORK  LEVEL 


MPS  to  MPS  data  shall  be  transmitted  as  packets  in  accc  dance  with  the  X.25  standard 
of  CCITT  (Reference  11).  In  particular,  packet  headers  shall  be  appended  by  the  MPS  Data 
Terminal  Equipment  (DTE)  for  handoff  to  the  Data  Communications  Equipment  (DCE). 
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